Connection to local .mdb using CR 10.5 x64 runtimes

[Former Member]

Hi,

I am using the CR 10.5 x86 and x64 runtimes for an application built in VS 2008. The application builds and runs correctly, and I am able to load and view a .rpt using an .mdb as the datasource.

-

---

In the x86 version of the application:

I use the CR 10.5 x86 runtimes, and the .rpt file was built using a DAO connection to an .mdb. I apply the following code to dynamically change the datasource:

public bool ChangeDatasource(string DatabasePath) // E.g. DatabasePath = "C:\newdata.mdb"

{

crConnectionInfo.ServerName = DatabasePath;

crConnectionInfo.DatabaseName = DatabasePath;

crConnectionInfo.UserID = "";

crConnectionInfo.Password = "password";

//Loop through all tables in the main report

crDatabase = crReportDocument.Database;

crTables = crDatabase.Tables;

for (int i = 0; i < crTables.Count; i++)

{

crTable = crTables[ i ];

crTableLogOnInfo = crTable.LogOnInfo;

crTableLogOnInfo.TableName = crTable.Name;

crTableLogOnInfo.ConnectionInfo = crConnectionInfo;

crTable.ApplyLogOnInfo(crTableLogOnInfo);

bool bOn = crTable.TestConnectivity();

if (!bOn)

MessageBox.Show("Failed to connect to " + crTable.Name);

}

crReportDocument.VerifyDatabase();

}

The above works perfectly in x86.

-

---

However, in the x64 version:

Using the CR 10.5 x64 runtimes, the application builds and runs correctly, and displays a simple report just fine.

However, when I use the code above, TestConnectivity() fails and I get the following error during VerifyDatabase():

"Error in File ____.rpt: Invalid mapping type value."

As I understand it, this is because the .rpt was built with a DAO connection, which does not support 64-bit. Thus, I am trying to alter the .rpt to use another connection. My results are as follows:

32-bit DSN, using DAO / ODBC / ADO: I can create the connection, but I still get the "Invalid mapping type value" error when running the code above in x64.

64-bit DSN using ODBC: I get an IM014 "The specified DSN contains an architecture mismatch" error in the Database Expert when trying to set up the connection.

64-bit DSN using ADO: None of the provider options seem to work when setting up the connection in the Database Expert. I get errors like "Data source name not found and no default driver specified".

Note, before anyone asks: Yes, I do have the 64-bit Access ODBC drivers installed, and working. I use them in another part of my x64 application, and they work correctly.

-

---

Any help would be GREATLY appreciated.

[Former Member · Accepted solution]

Don,

I double-checked again. There is no "crlogger.dll" on this machine (I have VS2008 / CR10.5 installed, as well as CR XI).

I really want to get this resolved, and will get a log file of my results as soon as I am able to find that file.

...Am I missing something?

- David

[former_member11696 · Accepted solution]

Hi David,

Sorry I've been off on holidays.

I'll try attaching it to the post. Rename the .txt to .dll, did so to get it through mail.

To disable logging just rename the dll.

What you may want to do is purchase a case on line, this issue is going to be too much for forums to handle.

Thank you

Don

[Former Member]

Sorry it's been so long, but here's an update:

I was instructed to drop the 64-bit development, so I did not get a chance to obtain any information via the debugger.

In any case, I'm 95% sure that the debugger would have simply shown that a report built with 32-bit ODBC does not work with the 64-bit CR runtimes.

If anyone here ever discovers a method for building a 64-bit ODBC report in CR 10.5 or CR XI, I would appreciate it.

[Former Member]

Thank you, Don!

I'll post as soon as I have some results.

[Former Member]

Don,

I do not have crlogger.dll anywhere on this machine. I have both CR 10.5 and VS2008 installed. Do you know where can I obtain it?

Edited by: DKouts on Aug 20, 2010 5:04 PM

[Former Member]

@Ludek:

I understood when you said that CR10.5 may not work with Acc2010 drivers. I just thought there was some confusion when you re-suggested using 32-bit Access drivers. I think we're clear now, and thank you for the updated link.

Regarding ADO.NET datasets, that's a valid option. However, I've already talked to my superiors about it, and they would like to avoid the additional data export that it would require, as our data structure in the .mdb is already quite huge and complex.

@Don:

My 64-bit app creates a 64-bit ODBC DSN, and (successfully!) uses the Access2010 64-bit drivers to put the data into the .mdb. Then it loads the report and sets the location to the .mdb's full local path. However, I get the "Invalid mapping type value" exception during VerifyDatabase().

Honestly, the above makes sense, because I can only test this with reports created under DAO (32-bit only) or ODBC (using a 32-bit DSN). I tried creating a report using a 64-bit DSN, but I get the IM014 "architecture mismatch" error when trying to connect the report to the db.

Regarding the logger suggestion, thank you! I'll try it as soon as I get the chance, and post the results here.

[Former Member]

Ludek,

I think there must still be some confusion here.

I am well-aware that I can design reports using the Access 2007 (32-bit ODBC) drivers. In fact, I have already tried this, and it works fine with my 32-bit app using CR 10.5 32-bit.

However, those reports do not connect when using my 64-bit app using CR10.5 64-bit. This makes sense, because the Access 2007 drivers are 32-bit.

The reason I have been trying to use Access 2010 is that, unlike 2007, it has 64-bit ODBC drivers.

-

---

I'll try to make this more clear, once again:

My 32-bit app, using CR 10.5 32-bit:

- Report built with DAO: Works

- Report built with Access 2007 32-bit ODBC: Works

- Report built with Access 2010 32-bit ODBC: Works

My 64-bit app, using CR 10.5 64-bit:

- Report built with DAO: (no 64-bit DAO) "Invalid mapping type value" error when running app

- Report built with Access 2007 32-bit ODBC: "Invalid mapping type value" error when running app

- Report built with Access 2010 32-bit ODBC: "Invalid mapping type value" error when running app

- Report built with Access 2010 64-bit ODBC: "Architecture mismatch" error when trying to design the report

-

---

You also said you would test CRVS2010 x64 with Access 2010 x64. Do you have a result for that yet?

-

---

P.S. Your first link results in an error. Can you provide a corrected link?

Edited by: DKouts on Aug 18, 2010 11:44 PM

[former_member11696]

Hi DK,

I was the one who was going to test this but I need a new image and thats goinf to take time to build. Plus we don't support Office 2010 yet but should be in the platforms once Cr is released.

In the mean time can you create the DSN in 64bit only on the runtime only PC and then in code set location and verify the database to see if that works.

Also there is a database logging dll included. To enable it go into the System Environment variables and add these:

• In your System Environments, add the following variables and values:

o LOGGING_ENABLED_ASSERT=1

o LOGGING_DIR=c:\logging

o LOGGING_ENABLED_RUNTIME=30

Restart your app, it may need to close VS 2010. Then test again and see what the logs indicate.

To turn logging off just rename crlogger.dll to *.old.

DAO will not work, I believe MS is only supporting 64 bit ODBC connections to access and not their native engine.

Thank you

Don

[former_member183750]

The new link is here:

http://store.businessobjects.com/store/bobjamer/en_US/pd/productID.98078100?resid=S6I@hgoHAkEAAGsiyV...

Please note that on at least two occasions in this thread I mentioned that this may not work with CR 10.5. E.g.; in the last post:

From a support standpoint, office 2010 drivers are not tested and not supported with 10.5 since 10.5 was released 2yrs previous to office 2010.

At this time, I'll leave this thread with Don, but I'd suggest considering other ways of supplying the data to the report - if only as a back up approach to the issue (ADO .NET datasets?).

Ludek

Edited by: Ludek Uher on Aug 19, 2010 7:12 AM

[Former Member]

...Hello?

[former_member183750]

I finally have an answer for you. BTW; if the solution provided below does not work and this is a critical issue, please create a phone case here:

http://store.businessobjects.com/store/bobjamer/en_US/pd/productID.98078100 

This is only a community forum, not "support" as such.

Your solution:

Since the CR designer is 32bit, if you are developing on a 64bit OS with 64bit Office, you will have to download the 32bit drivers for Office 2007 and use those for designing the report.

http://www.microsoft.com/downloads/details.aspx?FamilyId=7554F536-8C28-4598-9B72-EF94E038C891&displa...

VS 2008 would have already installed the 32bit CR 10.5 runtime, so the 64bit MSI may also need to be run on the dev box as well and the app compiled for 64bit only in order for everything to be able to work on one box.

From a support standpoint, office 2010 drivers are not tested and not supported with 10.5 since 10.5 was released 2yrs previous to office 2010.

Ludek

[Former Member]

...Any updates yet?

[Former Member]

...Have you been able to confirm one way or another on that yet?

[former_member183750]

Not yet. pls stand by...

Ludek

[Former Member]

Ah, I see. That makes more sense. Thank you, Ludek.

I'm looking forward to hearing what you find out when testing CRVS2010 with Access 2010 x64.

Thank you!

[Former Member]

Again, ODBC Access x64 drivers DO EXIST. One of the links you posted about this was confusion between a 32-bit DSN and a 64-bit DSN. The other is simply outdated.

The Access x64 driversets (including ODBC) come with Access 2010 x64. They also come in these downloadables:

Access 2010 Engine (x86 and x64): [http://www.microsoft.com/downloads/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en]

Access 2010 Runtimes (x86 and x64): [http://www.microsoft.com/downloads/details.aspx?FamilyId=57a350cd-5250-4df6-bfd1-6ced700a6715&displaylang=en]

As I said, I am already using the x64 ODBC Access drivers to put the data into the .mdb. I know they work. What I don't know is why CR 10.5 won't allow me to connect to them.

Any suggestions?

Edited by: DKouts on Aug 9, 2010 10:03 PM

[former_member183750]

The problem here is that you are looking for CR 10.5 to be couple of years forward compatible. Access 2010 is not listed as a supported database in platforms documentation for CR 10.5.

So, we have two options;

1) As before, .NET Datasets

2) CR2010 for VS 2010. Which of course brings up at least two new issues;

a) You need .NET 2010

b) CRVS2010 is only in Beta at this time with RTM expected towards the end of this year

I'll test CRVS2010 with Access 2010 and confirm this works. If not, I'll update R&D and see how they want to handle that.

Ludek

[Former Member]

Regarding ODBC 64-bit Access drivers:

They DO exist, and I can confirm that they work. I am already using 64-bit ODBC (using a 64-bit DSN) to put the data into the .mdb.

That's why it baffles me that the CR .rpt won't connect using 64-bit ODBC, since the drivers are in place and working.

-

---

Regarding using ADO.NET, I'd prefer to avoid having to export my data from the .mdb into an .xsd dataset. I'll try this if nothing else works, but I'd like to determine whether ODBC x64 is possible first.

[former_member183750]

Ok. I don't know bout 64 bit drivers. The second link I posted is from MS, so I took that to be relatively safe feedback. I googled one more time for;

64 bit odbc access driver

All the info I get from that search is that there is no 64 bit ODBC driver for Access. The error you are getting is coming directly from the ODBC layer and from what I read it means; there is no 64 bit ODBC driver present. Perhaps you can check with MS what other conditions woudl raise that error? If you can point me to a 64 bit version of the ODBC driver for Access, I'll install it here and have a look.

Ludek

[Former Member]

Update:

After installing the CR Basic VS2008 SP1 package you linked, and fixing my aforementioned crash (found the error, easy fix):

64-bit application (using the CR 10.5 64-bit runtimes):

Report using DAO:

• "Failed to load database information" Makes sense, since there's no DAO x64.

Report using ODBC (32-bit DSN):

• If using my ChangeDatasource function above, I get an "Invalid mapping type value" error during VerifyDatabase().

• If not using that function, I get an "Unable to connect:" error, then the logon prompt. Entering the correct password for the .mdb gives "Logon failed. Please try again."

Report using ODBC (64-bit DSN):

• I cannot create a report with this type of connection. I always get error IM014 ("The specified DSN contains an architecture mismatch") when I try to add a new connection or change the existing connections in the report.

Report using OLE (using ODBC 64-bit DSN):

• Same as above, cannot create this connection.

...Any other suggestions? I'm out of ideas now.

[former_member183750]

Googlig the error, according to [this|http://us.generation-nt.com/answer/64-bit-srs-using-an-odbc-connection-an-access-database-help-163996731.html] and [this|http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/dfbd0406-bc69-436e-998b-7fc454012f91] and other hits there is no 64 bit odbc driver for Access. Being far from Access guru, if that is the case, your best option is to use ADO .NET Datasets - if you can use 64 bit .NET APIs to connect to the Access database, then pass the dataset to the report.

Info on how to work with .NET Datasets and Crystal Reports;:

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/401c4455-a31d-2b10-ae96-fa57af5a...

Info on how to troubleshoot issue with CR and .NET Datasets;

[Troubleshooting Issues with VS .NET Datasets and Crystal Reports|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13270] [original link is broken] [original link is broken] [original link is broken];

Ludek

[Former Member]

Thank you, Ludek.

1) I'll try it and let you know. (Probably will be Monday, as some other priorities came up this morning.)

2) The report was created in Crystal 10.5.

3) The report was originally created using a DAO connection. For debugging purposes, I deleted all the db connections, saved the .rpt, and am trying to create a new connection.

4) With zero db connections (just a template .rpt), the report displays in x64. With my code (the function above) commented out and using DAO or 32-bit ODBC for the report (the only connections I can seem to make, see above), I get a crash, no logon prompt. If needed, I'll do some digging into the crash on Monday when I get the chance.

[former_member183750]

This sounds like we should be able to get it going Monday. SP 1 will help, making sure our report is based on ODBC and fingers crossed, voila...

Have a great weekend,

Ludek

[Former Member]

P.S. Thank you for moving this thread to the correct area.

[former_member183750]

Interesting. Let's try the following:

1) throw SP 1 for CR 10.5 at this and see what that does for us:

https://smpdl.sap-ag.de/~sapidp/012002523100009351512008E/crbasic2008sp1.exe

2) What version of CR was the report created in?

3) Was the report created originally to use DAO or ODBC? (If you go to the Database menu and select "Set Datasource Location", expand the "Properties" node. Here at Database type it will tell you what db connection type the report was designed with. And you can change the connection type here also.)

What I'm thinking here is, if the report was originally created with a 32 bit DAO connection, we will not be able to go to ODBC in code be it 32 bit or 64 bit. You'll have to convert the report in the design view from DAO to ODBC. In the full versions of CR you get the InProc RAS SDK and you can convert to other database logon connection types, but not with the bundles.

4) If you comment out the database logon code, the report should prompt for the db logon parameters. Does it? What happens when you fill out these parameters manually?

Ludek

[Former Member]

Yes, the ODBC datasource is 64-bit. That was the very first thing I checked.

To clarify:

I can make a connection in the .rpt to a 32-bit ODBC DSN. However, this generates the "Invalid mapping type value" error when I load the .rpt in the x64 application.

I cannot make a connection in the .rpt to a 64-bit ODBC DSN at all. I receive the "The specified DSN contains an architecture mismatch" (error IM014) in the Database Expert (in VS2008) when trying to change the .rpt.

[Former Member]

Ludek,

Please read my post, rather than skimming.

As I said:

"...because the .rpt was built with a DAO connection, which does not support 64-bit. Thus, I am trying to alter the .rpt to use another connection."

I am well aware that there is no 64-bit DAO. That's why I am trying to use another connection type for x64.

I have already tried 64-bit ODBC, and received an error. (see my post above)

I have also tried ADO with a 64-bit DSN, and received an error. (see my post above)

I would really appreciate any assistance with this.

[former_member183750]

My bad... when I moved you post from the .NET Development - Business Objects Enterprise forum to t his forum, I overlooked the bottom part of the post...

Typically, when using 64 bit CR, people forget that they also need to create a 64 bit ODBC datasource. Are you sure your ODBC datasource is not 32 bit?

See [this|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/10d5fa88-2013-2c10-c9a5-f11963607d4e] article.

Ludek

[former_member183750]

There is n o 64 bit DAO engine, thus the error. You will either have to drop down to 32 bit runtime, or connect via 64 bit ODBC connection, or ADO .NET Dataset.

See the KB [1463678 - Error: Failed to load database information. Details: The database DLL 'crdb_dao.dll' could not be loaded|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/oss_notes_boj/sdn_oss_boj_dev/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/scn_bosap/notes%7b6163636573733d36393736354636443646363436353344333933393338323636393736354637333631373036453646373436353733354636453735364436323635373233443330333033303331333433363333333633373338%7d.do].

Ludek

Follow us on Twitter http://twitter.com/SAPCRNetSup