It is used strictly inside my programs to facilitate crystal. It's readonly, so you can't hurt anything, and unless you're really paranoid about security/privacy it won't be a crisis if someone gets a hold of that User ID and password combination. I call it something cryptic, but the gist is I usually call the DSN 'CRSS' which stands for Crystal Reports SQL Server, and I don't use that ID for anything except crystal, and in general, the User ID has READONLY access (Select access) only, to all tables in the database. I use a separate UserID and password for all my crystal reports, and I set up a DSN with ODBC Administrator to define it. Since I can't predict or dictate what the SQL Server (that's the SQL Server, not the Windows Server) will be, the name is passed to the program as a parameter in the desktop shortcut. Second, I access a SQL Server database via ODBC. The information is there, but I did not find these articles particularly user friendly.
#CRYSTALVIEWER SOFTWARE DRIVER#
Each connection does have different properties as it now reads the driver ODBC, OLEDB or Native. DeleteAll and add the new properties in for ODBC. If you will be running reports from older versions of crystal, I recommend using the property. They are explained in the following document: The biggest changes were the new ConnectionProperties in version 9.0 and later. This basic document is a good place to start. Specifically, I access a SQL or Access database via ODBC, but either database will work with the code samples. First, I'll refer you to the Knowledgebase Articles that give the needed information, and second I'll give you code samples to run a report given the methods I use.
0 kommentar(er)
