CLFN labview crash

[falkpl]

Thanks all for the posts this saved me. I just upgraded an application to 2010 with an extensive set of dll wrappers.  2009 was nice enough to silently (NO errors were generated) run my dlls despite the incorrect calling convention.  2010 crashed immediatly.  fixing the calling conventions fixed the crash.  There really should be a warning since I have more applications than I can count to support with potential upgrades.  I could not find any mention of this outside of this set of posts. 

Conclusion: double check all dll calls for correct convention and error handling when upgrading to Labview 2010 since the optimization nolonger allows for labview to help out as much as in the past.

[Zing]

Hello Paul, I'm having problems using the libmySQL.dll with mysql_real_connect function (error 1097) with LabVIEW 2010 and I'm not sure from reading this thread what calling parameters you used to get it to work in the end. I'd be very interested to know and if you could post your connect wrapper, I would be very grateful. Cheers!

[falkpl]

I was wrapping dlls from ANDOR SDK3.  In labview 2009 they actually worked fine when I was mistakenly using c convention.  In labview 2010 the same exact calls crashed immediately.  Fixing the convention to use WINAPI (which is what I should have used in the first place because this is what the header file specifies) solved the issues I was running into.

Did your wrapper work in previous versions of labview?

[Zing]

I'm planning to replace my existing ODBC calls with the libmysql conection and I have not got anything working yet. The mysql_init does work. I'm using the WINAPI convention but I'm wondering if any of the parameters need to be changed to make mysql_real_connect work.

This returns error 1097

[d_sdl]

If you get libmysql.dll working in 2010 let me know. I ran out of time and had to switch back to using ODBC and the database toolkit.

[d_sdl]

Thanks to Rob and Rolf for their help. Finally got it working. The problem was that an unsigned long under 32 bit LabVIEW is an uInt32 not an uInt64.

[Zing]

Hello d_sdl,

Well done for getting it working. Is there any chance you could post your connect code in the screen-shot as I'm still not sure what the 'SZ' parameter type (as it is displayed in your screen-shot) should be?

Cheers,

Zing

[rolfk]

Not 100% sure but I would suppose it's the (signed) pointer sized integer.

[d_sdl]

Zing

SZ is a signed Pointer-sized Integer. I used this data type for the MySQL pointer based on Rolf's earlier suggestion to use a "pointer sized integer CLN datatype for all pointer types (MYSQL*, and those NULL string parameters)". I don't know for sure if it should be signed or unsigned. It worked with the signed type so I didn't try the unsigned case.

[rolfk]

signed and unsigned pointers is mostly just a cosmetic distinction. However if you use one of these for a particular pointer I would recommend to stick to it throughout all LabVIEW VIs. Otherwise you could run into corrupted pointer values due to sign extension arithmetic rules being applied when LabVIEW tries to convert from signed to unsigned and vice versa.