monacoassociates
asked on
"open database session failed" error on one Crystal Report when directed to certain database
We market an application that is created in Visual Basic 6, uses an Access database (4.0), and has a number of Crystal Reports (8.5) that access the database via OLE DB. One of our long-time users has just recently started having a problem with one of the reports, receiving the Crystal Reports error message "open database session failed" when they try to run it. Their other reports are still functioning correctly, including reports that draw from the same columns of the same table. Since all of the reports run through the same code sequence and use the same connection string, that would mean that it is not a connectivity problem, wouldn't it? They have sent me a copy of their Access database and I get the same error when I use their database, but not when I use any other database, so that would indicate no version incompatibility in the report itself. Using Crystal Reports directly, without running it through Visual Basic, the report will run against their database without problems, which suggests there is no problem within the database. (I have tried compacting and repairing the database with no effect.) What else is left? Does anyone have any other suggestions as to where to look for the problem?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the suggestions. I have found a simpler solution, however. While doing a web search on decompiling, I came upon this website: http://www.jamiessoftware.tk/articles/accesscorruption.html which suggested creating a new, blank database and importing all database objects into it. That proved to be successful. I guess I'll give you the points, DatabaseMX since you pointed me in a useful direction.
Thank you.
But ... keep the decompile procedure handy ... because it may not always be convenient to do the import scenario ... especially if you User Level Security implement ... and ... the import may not always fix the problem. I've seen Decompile fix a number of very 'weird' situations.
mx
But ... keep the decompile procedure handy ... because it may not always be convenient to do the import scenario ... especially if you User Level Security implement ... and ... the import may not always fix the problem. I've seen Decompile fix a number of very 'weird' situations.
mx
ASKER
Oh yes, I did take note of that procedure for possible future use. One cannot have too many options for untangling databases. Thanks.
So it seems that only thing left is the code in your VB app that is opening the report.