Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Using OLE connections to MS SQL database
- Thread starter poli13
- Start date
I think you might mean OLE DB.
For ver 8.5/9. the principle is the same.
8.5= Click Database, Add Database to report,
Under the More data sources, click OLE DB
Make a new connection,
Now For the Provider Tab pick MS OLE DB Provider for SQL Server, Click next(or the connection tab)
Type in the server name/ip adress for 1) Select or enter Servername, 2) Enter password, or if your can authentication to sql server then choose Integrated.
3)SPecifiy the db.
thats it.
If you use Integrated security, then the person who runs the report has also have a account on SQL server with the correct credentials.
Fred
For ver 8.5/9. the principle is the same.
8.5= Click Database, Add Database to report,
Under the More data sources, click OLE DB
Make a new connection,
Now For the Provider Tab pick MS OLE DB Provider for SQL Server, Click next(or the connection tab)
Type in the server name/ip adress for 1) Select or enter Servername, 2) Enter password, or if your can authentication to sql server then choose Integrated.
3)SPecifiy the db.
thats it.
If you use Integrated security, then the person who runs the report has also have a account on SQL server with the correct credentials.
Fred
- Thread starter
- #3
While I may have answered your OLEDB quuestion, I couldnt't help to think that your real issue of slow reports hasn't been replied.
I haven't done any benchmark between odbc and ole db but, the biggest performance gain can be made by optimising your selection statements so it gets passed to the db. This way the amount of data returned by the server will only be whats required. If all the data is returned to the client, then Crystal will do the filtering locally. This means that the network and the client may be the bottleneck.
Where to look... Do a Database, Show SQL Query.
Have a look the SQL thats generated by Crystal. If you can see a Where clause section thats a good start. That means CR is sending some of the filtering to the db. If any or all of the where filter is missing, then you need to optimise your filtering. There are a number of postings which discuss this and there is also a FAQ in one of the forumns.
You could also post your SQL and the Selection formulae if you need help.
Note: if all your record selection formulae is passed to the the db, then the db will be the bottleneck.
Also any sub reports will severly hinder report performance.
I'll also be interested to see what difference odbc vs OLEDB made.
Fred
I haven't done any benchmark between odbc and ole db but, the biggest performance gain can be made by optimising your selection statements so it gets passed to the db. This way the amount of data returned by the server will only be whats required. If all the data is returned to the client, then Crystal will do the filtering locally. This means that the network and the client may be the bottleneck.
Where to look... Do a Database, Show SQL Query.
Have a look the SQL thats generated by Crystal. If you can see a Where clause section thats a good start. That means CR is sending some of the filtering to the db. If any or all of the where filter is missing, then you need to optimise your filtering. There are a number of postings which discuss this and there is also a FAQ in one of the forumns.
You could also post your SQL and the Selection formulae if you need help.
Note: if all your record selection formulae is passed to the the db, then the db will be the bottleneck.
Also any sub reports will severly hinder report performance.
I'll also be interested to see what difference odbc vs OLEDB made.
Fred
- Thread starter
- #5
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question