Database Toolkit - Get Database Information

[DL84]

Hi All,

I'm struggling a bit with this toolkit, and thought I'd bring it up on here for some input.

Using the included functions with that toolkit, I'm able to connect to my database, but i'm having trouble writing to it (Error -2147217913).  I'm a bit concerned that maybe my data types don't match, so in order to confirm, I noticed in the examples given with this toolkit there was a VI that gets your database information (Column names, tables, most relevant - data types per column name.).  Something odd happened that I'm not sure if its supposed to:

I changed the UDL address of the example database, to my database's UDL...nothing else, just to get a list of datatypes.  Now using their UDL it finishes cleanly, w/no error.  With my UDL - I receive Error -2147217900 occurred at Conn Execute.vi->DB Tools List Columns.vi->Get Database Information.vi.  Interesting eh?  But it does show every column name/and data type, wonder why it fails though?

Anyone have some recommendations of how to troubleshoot next? Or how to interpret this?  I'm betting if I can figure out why its failing in the example program, both failures are maybe tied together?

[Kenny_K]

Take a look at this post, seems there is a knowledge base that has information on your error.  (also, try doing a search on the forum for error 2147217900)

If that does not help you out, post with any results from looking at the different articles, and we can go from there.

[Aashish_M]

Hi Leachdor,

Please refer to these two KBs linked below;

http://digital.ni.com/public.nsf/allkb/D8FF30B4409602B386256F3A001FC96C?OpenDocument

http://digital.ni.com/public.nsf/allkb/22A45DF5C85AB3F286256CC30073C5AC?OpenDocument

These links should help.

[DL84]

Aashish,

I went through and double checked for all of those syntax requirements.  I am able to use the "Get database Information" example to work without error now, however my application where I try and write to that database still is coming up with the error.

The following has been confirmed:
*The path to the UDL that points to the database in question contains no spaces.
*Column Names contain no spaces or special characters. (Spaces use underscore instead)
*Table names contain no spaces or special characters
*All values in the database are either string (50 character limit) or Single for numerics.
*All values in labview are either string or single numerics (I believe...i'm not sure how to check representation on a single element of a cluster without pulling the control out of the cluster so I can right click and "view representation"...Its not a visible option as far as I can find when in the cluster...and I don't want to risk pulling it out and changing the order of cluster items...which would do knows what to the column order in the database lol)

Now that the get database information is working, but the other isn't - any further ideas how to troubleshoot?

[Aashish_M]

Hi Leachdor,

I have noticed that you have posted on this issue before and the recommended link was:

http://digital.ni.com/public.nsf/allkb/3DC9DC2D850A087686256B0B007C355F?OpenDocument

Did this help?

Could you tell me which VI in particular is causing the problem? (please do a highlight execution test to figure that out)

Also you have to make sure that you are not writing any empty strings!!

[DL84]

Hi Aashish!

Good news, figured out the problem...I WAS writing a null to the database (by accident), and while access doesn't mind them - the toolkit is based on SQL standard which i believe does.  The program had a cluster that was being initialized, and fed into a loop where it waited for user action. (So we didn't have left over garbage in each field whenever the app ran.)  Once the user input all their data, that same wire was fed into the input to populate the array. I thought it would update the cluster as the controls were changed, but I guess the only way to change elements is to unbundle, change and rebundle. (At least thats how it behaves)

Appreciate the help, but while on the topic maybe you can give me a pointer, the only way I could work it so a fresh copy of the data was sent into the cluster, was to make a local variable of the cluster and wire that to the input (See picture).  Rather than get yelled at later if I need more help, any idea how to reduce that local so we don't require a duplicate copy of the data?  (avoid race conditions, etc.)  Or would you even?  Guess it boils down to, is there another way to update the cluster in there?  I can unbundle, and rebundle, but I'm not sure what I'd do between the two to update all those to feed into the database...its a bit confusing to describe but I think it gets the idea across lol.

I was thinking about a way to do it...and thought maybe I need an indicator for each control, then when the indicator changes, feed that into the control cluster to update from intial and go from there...but thats a copy of data the same size as the local would make, I'd think.

[Aashish_M]

Leachdor,

I am not to sure what you really mean, but I know you can make an entire cluster a local variable, unbundle it later on and proceed with the rest.

Hope this helps.

[DL84]

Gotcha,

thats how I did it!  Just wanted to make sure there wasn't a better way in case I need further help down the road.  You become an outcast if anyone calls you on using locals here lol.