x64 release not working

[ISITEC_RIEPER]

I develop an x64 application, which uses a SQL database and it works in debug and release, if I start the application from cvi. The application does not work (I get "Automation error code -2147024809 0x80070057 invalid parameter.") if I start it from outside if Windows, e.g. by starting it from the explorer.

Did anyone else have such a problem? And how to solve it?

[ISITEC_RIEPER]

I made the smallest possible out of my project and the problem still exists. Maybe someone can test it and say if it is an problem with cvi or my pc.

The problem seems to be a problem with cvi and SQL.

These are the combinations and errors I get:

• x64 debug build, started from within cvi -> working
• x64 debug build, started from windows explorer -> do not get a connection to the database
• x64 release build, started from within cvi -> working
• x64 release build, started from windows explorer -> get a connection to the database, but a simply SQL request (SELECT * FROM Module) is not working and gives the error ("Automation error code -2147024809 0x80070057 invalid parameter.")

Can anybody tell me, what can cause this?

[ISITEC_RIEPER]

Ok, as I found out how to configure a 32bit ODBC on a x64 system I tried my program as 32bit version and it works flawless. So it seems that this is a problem with 64bit programs/libraries!?

[BRennhofer]

are you using multithreading?


Because this info is maybe a solution for your problem:

"a customer that is using CVI 2012 and SQL Toolkit 2.2 on a Windows 7 64-bit OS. When the customer builds a 32-bit application to communicate with his mySQL database and enables multithreading using the command DBInit (DB_INIT_MULTITHREADED), everything works fine. However, when he builds a 64-bit application, he gets  the following error when running his application:

"Automation error code -2147024809 0x80070057 Invalid parameter"

In both 32-bit and 64-bit applications, he is able to use DBInit (DB_INIT_SINGLETHREADED) without problems, but due to their application requirements, they need to be able to do multithreaded communication.

Solution:

Calling DBInit for multithreaded does not actually set the threading model to multithreaded. It instead defers the decision until later [......]use CA_InitActiveXThreadStyleForCurrentThread(0, COINIT_MULTITHREADED) to set the threading model
"

[ISITEC_RIEPER · Accepted solution]

Thanks, I will try it (although we have decided to go with the 32bit version as it also gives less problem with the distribution) and this also explains why my other program is working ok in 64bit.

Do I have to do this in every Thread that is using SQL functions? Because DBInit() is just called once, but the function name of CA_InitActiveXThreadStyleForCurrentThread implies that the configuration is only valid for the current thread?!

[ISITEC_RIEPER]

So I tried it and it worked 🙂

So thanks for the solution.