• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 776
  • Last Modified:

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

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?
0
jgbreeden
Asked:
jgbreeden
  • 2
  • 2
1 Solution
 
mlmccCommented:
Are you running the same databse on all machines or does each environment dev/test/ have its own database?

mlmcc
0
 
jgbreedenAuthor Commented:
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.

j
0
 
mlmccCommented:
ARe they physically the same or copies in different locations?

mlmcc
0
 
jgbreedenAuthor Commented:
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.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now