web based application

[dems]

---

@mikeporter wrote:

Gee I wish I had talked to you when I ran into the problem. Not knowing any better I thought NI's Premier Support and LV development team would know what was going on. Guess not...

Mike...

---

I would always backup talking to a person with checking google. Results 1 and 3 on google are what you want, and I've tried both of these and know they work:

(worked before 2013) http://www.ni.com/white-paper/7747/en/#toc7

(only work in 2013) http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/ws_debugging/

---

My VI is a simple query. Nothing special about it. I've attached screen shots of the VI and front panel with the expected result and the web method VI with the xml output in the browser. It doesn't show any errors.

---

OK, so you have a VI "untitled 2" with an error in, error out, and sum out. You know this VI functions correctly. Create a new web method, drop this VI in and put an indicator on error out and sum out. Then follow the steps above for debugging web method VIs and determine if you are getting an error of some sort.

Right now I'd guess one of these issues:

1. The error wires ensure you don't disconnect from the database until after you convert the database variant into data. Since I have no idea what ODBC magic happens when you call these functions, ensuring that you call these functions in the right order makes sense to me.

2. The code is throwing an error in the web service mode which it isn't throwing in normal labview debugging mode. I know db toolkit worked in 2011 web services, but I only have used the two together in 2011.

3. Some time between 2011 and 2013, db toolkit stopped working in web services and no longer throws errors when it doesn't work. If you believe it is this last issue causing your problem, I would call the support team to report the bug.

[Mateus23]

I connected the error in and error out on the web method VI and strange things happened. I've attached print screens of the xml outputs.

When I run in debugging mode as you suggested it doesn't show any errors and it returns the correct result. When I deploy the web service normally it shows up an error on the odbc connection and doesn't return the correct value.

I searched here in the forums and turns out this error could be caused by using the 64-bit MySQL driver instead of the 32-bit version, even on 64-bit OS systems. But I think that I already had this problem when I first configured and tried the odbc connection. But I'll try to install the 32 bit version again.

[Sam_Sharp]

Yes - it's something that I've had problems with before as it's not very clear - the version of the ODBC driver has to match the 'bitness' (32/64 bit) of the application, not the OS.

One way to check which drivers are installed is to run odbcad32.exe that's located in the SysWOW64 Windows directory (as this is the folder for the 32-bit version). Stupidly...the program is called odbcad32.exe even for the 64-bit version (in the System32 directory). Windows is stupid 

If the MySQL ODBC driver shows up there then it's probably installed correctly and you can even create a test connection just to rule out any problems with the driver/server.

[Mateus23]

Yes, I remember now that when I set up the ODBC connection I had to use that file on the SysWOW64 folder because the MySQL driver didn't appear if I went directly through the control panel. So I think that I have the correct version installed, because if I didn't all my database accesses in my labview applications shouldn't work and I only have this problem with the web methods VIs.

Anyway I'll try to reinstall the MySQL ODBC driver, but I don't think it will do anything...

[Mateus23]

Reinstalling the 32-bit version ODBC driver didn't solve anything. Anyone knows what could be causing this issue and how can I solve it?

It's really weird that it works well running "normal" VIs and while debugging the web method VI, and when I'm running the web method normally it gives this error...

[dems]

Unfortunately this is beyond my knowledge. ODBC stuff is magic to me. I know you use a pretty short connection name. Is there a chance that this connection name is just an alias for something, and while labview knows what the alias means (so it works in debug mode), the application web server doesn't know the alias? Could you do a full connection string instead? When I had it working a few years back, it was with mysql and I think I was using a full string saying ip address, username, and password.

[Sam_Sharp]

I use the following connection string for MySQL connections:

Provider=MSDASQL.1;Persist Security Info=False;Extended Properties="Driver={%s};Server=%s;Port=%d;Database=%s;User=%s;Password=%s;Option=3;"

Instead of using udls or ODBC connections I create the connection information myself using a format into string. This means you can define the connection entirely in LabVIEW without any external code/files. The "Driver={%s}" part should contain the name of the ODBC driver e.g. "MySQL ODBC 5.2 ANSI Driver"

Might be worth a try?

[Mateus23]

Sam_Sharp, it worked! 

Thank you!

[mikeporter]

To complete the discussion of connection strings, a UDL is really just a text file containing, you guessed it, a connection string.  

A trick I have used many times over the years is to use the datasource editor to create and test a udl. I would then open the resulting udl in notepad and copy out the connection string.

Mike...