Database Connector Error with CR11.5, .net, after replacing vfp8 with vfp9

Posted on 2009-02-19
Last Modified: 2012-05-06
I have a .net 2005 Win app that uses Crystal 11.5R2 with VFP data.  The current, working version uses the OLE from vfp8.  We updated to the vfp9 OLE, and changed some of the data selection criteria in the .net code to take advantage of the stored procedure abilities in vfp9.  The reports are unchanged--they were originally written to xsd file defs, and we have always selected datasets and passed them to the report before viewing.  

Everything works on the development machine with the new version. But certain reports are failing on installed test machines with "Unknown database connector error".

I don't know if it is related, but we are having a much harder time building the install (installshield X) using the crystal merge modules than we did with the last version.  With our old version, we had concluded that we only needed one of the smaller crystal merge modules, so we started building this new version with the same merge module, but it would fail to register craxdrt.dll.  We ended up putting the full crystal enterprise merge module in the project (300Mb) before it would install properly on a clean test machine (XP pro or home, SP2 or 3).

And most of the reports run just fine.  The reports that fail all have subreports, and      they use datasets that are filled from the new stored procedures. And they open without errors if the dataset is empty. Reports that use those same datasets but don't have sub reports work fine. Other reports with subs work fine.

The fact that they all work on the development machine seems to confirm that all the field names, table names, and field types in the dataset that gets returned are all correct.  I even copied the exact data folder from a test machine where it fails over to my development system, and it runs perfectly.

So, assuming it had to be something in my dev environment that was missing from the test machines, I tried installing a complete CR11.5R2, a complete VFP9 standard, and a SP2 update for .net Framework on to the test machine.  No change, same reports still fail.  The only thing I haven't installed is the complete visual studio 2005.

Everything I have read on the connector error seems to lead back to permissions, but VFP does not use logons, and we are running administrator level users on freshly loaded test systems.

So either something is fundamentally wrong with my crystal merge modules, or something about the way the VFP9 stored procs return data is different than just selecting from tables.  Obviously the code in the stored procs has a huge effect, but if it works on the dev machine, what could I be missing?
Question by:jgbreeden
    LVL 100

    Expert Comment

    Are you running the same databse on all machines or does each environment dev/test/ have its own database?

    LVL 5

    Author Comment

    Hi mlmcc,

    Its exactly the same. The exact data files and dbc, with the same data, fail on the test machines and work on my dev machine.

    LVL 100

    Expert Comment

    ARe they physically the same or copies in different locations?

    LVL 5

    Accepted Solution

    We got it working by focusing on the Crystal merge modules, although I still have no idea what the actual problem was.

    Turns out that in our old project, in addition to the smaller merge module (cr115_rdc_runtime) a former employee of ours had figured out that we also needed a separate crystal .msi file (crystalredist115_x86.msi) to get it to install correctly.  That msi had been added as a "custom action" in the old Installshield project, and we missed that when we created the new installshield project.  

    I'm not sure what that msi does that the full crystal merge module does not do, but when we went back to running that msi as a custom action, crystal installed just fine with the smaller merge module, and all my problems magically went away.  That msi is about 80Mb, so that is a big improvement over the full merge module too.

    Thanks for responding anyway.

    Featured Post

    IT, Stop Being Called Into Every Meeting

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    Suggested Solutions

    This article describes relatively difficult and non-obvious issues that are likely to arise when creating COM class in Visual Studio and deploying it by professional MSI-authoring tools. It is assumed that the reader is already familiar with the cla…
    In my previous two articles we discussed Binary Serialization ( and XML Serialization ( In this article we will try to know more about SOAP (Simple Object Acces…
    In this sixth video of the Xpdf series, we discuss and demonstrate the PDFtoPNG utility, which converts a multi-page PDF file to separate color, grayscale, or monochrome PNG files, creating one PNG file for each page in the PDF. It does this via a c…
    Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

    754 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now