CException only covers MFC exceptions. If your exception is a C++ exception, you should catch the appropriate exception class or type. If your unsure what exception class or type could be "thrown" in a particular context, then it would be advisable to research "exception handling" in MSDN as their are different types that you should get familiar with. If you are in a hurry, you can catch "(...)" which will get just about anything, but this will possibly be frowned upon by some in the community since you basically lose the exception context and basically defeat the exception mechanism. Using "(...)" essentially turns exception handling into an overpriced "goto". To be fair, there are likely some in the community that feel "(...)" is ok to use and even handy. I find myself sitting on the fence with this one. If the exceptional condition is avoidable, it might be better to locate where it's getting thrown, and prevent the condition in the first place. It just depends on the exception context since some exceptions are, by design, unavoidable, real world, common occurences like file and database exceptions. Some just shouldn't happen like divide by zero and memory access violations These usually indicate flawed logic and should be removed/rethought/redesigned instead of wrapping in a try/catch. Thats just my 2 cents.

hi, I think your problem lies in your code itself.. Whether u are using RDC ( Report designer Component ) to connect ur datasource ? Anyway , download "cr_rdc_dbconnectivity.pdf" from Business Objects website. support.businessobjects.com/communitycs/technicalpapers/cr_rdc_dbconnectivity.pdf You can find more info abt CR 8.5 from this website.. Regs, vinsankar

I cannot really compare it to anything else. When we decided to convert our payroll app to C++ in 1997, Crystal was pretty much the only game in town. It is also quite widely used. It has a nice GUI editor where you create report files by pulling data from a database source. The finished report is an .rpt file that you distribute and use the CR engine to display/print. I suggest you download rdccpp85.exe from the BusinessObjects site. It has an example on how to call a report from C++. It lacks examples on how to pass an argument to it though, but ask if you need it :) Also. I have two books on Cr9 on the shelf. Both are OK. One is Mastering Crystal Reports 9 from Sybex, the other is Crystal Reports Essential by Jill K Howe from Premier Press. Both are avalable from Amazon. I had a quick chec at the Visual Reports site. It seems similar. I also see that there is an eval version you can download. for us, we stick with CR despite it's quirks. We are taking about a commercial app here, with a lot of reports. So I would rather not have to recreate those. FWIW, we are licensed for CR version XI, but selected to use CR9 for now, "because that is what the bulk of the other vendors use" Your selection will also depend on what fees if any are on redistribution. A crystal developer license allows pretty much unlimited distribution.

But until you actually step into the Open() call, you'll not know the cause of the error. I've only done one article dealing with record sets. See if this is of any help. "Approved Workmen Are Not Ashamed" - 2 Timothy 2:15 "Judge not by the eye but by the heart." - Native American Proverb

Thank you for the suggestion. But, in the SDI, only the first main form has database access, as in, if I use Edit fields and look to assign variables to each, I automatically get a drop-down list of the table column names in the add-member variable dialog. Subsequent dialogs do not have this facility. How do I go about that? And what should be the base type of subsequent dialogs? Just CDialog? Thank you again, Sir