-
Up until last week, the Crystal Reports section of my application was working fine. I have four separate reports, all linked to the same database, and they did what they were supposed to do when told to do it.
Then, one of the four reports began to malfunction. The others still work fine, mind you. It began to give me an error message that said "Error in file links. Warning: Fields in the report from the file 'Device' cannot be linked." Device is one of the tables in the database I am using. Now it gives me an error message for every table in the report except for the first table used. The fields from the other tables are not populated when I run the report.
The really strange thing is that the report previews fine in Crystal Reports. I checked all the database properties in this report against the other reports, and there are no differences. I am completely stumped. Does anybody have any idea what is going on here?
Thanks,
Jonathan
-
Well, I found out why the weirdness was occurring, but that is not a good thing. Turns out that one report was the only one set to verify on every print (obviously I hadn't tested the app too extensively prior to discovering this), and I guess Crystal Reports doesn't consider previewing the report a "print". Now, it seems that my database has changed in some way that makes it fail to cooperate with both Crystal Reports and an add-allowable True DBGrid, although it still works fine with another True DBGrid that does not have add and delete enabled, and it works fine with a regular DBGrid. I am getting very confused. Has anybody else noticed this sort of behavior? I recently downloaded Service Pack 3 and the ADO 2.1 files, but I only added one reference, to ADO 2.1, and I took that off soon after without changing any properties of objects (I just wanted to try something with ADOX, and it didn't work). The ADO recordset objects I use still work, too, and one of the ADO control/ True DBGrid groups still works. I am working with an Access database with Jet 3.51. All of the problem areas include some use of Microsoft DataShape, but not all things that use DataShape are acting up.
In conclusion, please ignore my laments about Crystal Reports. But if you want to humor my laments about data and control interaction in my application, your help would be much appreciated.
Thanks,
Jonathan
[Tearing out hair and balding rapidly]
-
Let me just throw another spanner in the works. I've been using Crystal 7 quite extensively, with both Access and SQL server.
There are many pitfalls you can fall into using Crystal Reports of which here are a few I have noted when using code to print reports: -
1. Crystal Report databases are case sensitive, so if somehow your databases get changed the report will need verifying.
2. Like you mention, Verify on Every Print doesn't always work, whether it be in preview mode or not.
3. Adding / Removing fields will screw up the report. Because the report knows it's been changed when collating the data the field was/should be recognised by the report.
4. (SQL Server only / ODBC) The datasource names used in the ODBC setup are case sensitive.
5. (SQL Server / ODBC) The username / password must be used EXACTLY as entered in the ODBC setup screen.
6. A database field/formula in the header section of a crystal report will expand when you tell it to do so in the formatting, but not correctly in the footer.
-
Sorry, I also forgot to mention that table and field names are case sensitive.
