Extracting one column from Database

[tst]

Here they are as 6.1. I don't have that installed anymore, so I can't convert more back. Maybe someone else can.

As an alternative, you can try LabSQL, which doesn't do all the stuff Mike's VIs do, but does do the basics.

[msimpson]

That's great...I have 6.1 on another machine.  We only had the 6i around since it was the only one we had with the Database Connectivity Toolset.

Thanks very much!

Mark

[msimpson]

Hmmm...Seems to be a problem here.

When I open the Open connection VI it's got errors right off the bat.

When I dig deep it seems the connectors on the Error Code Database VI are incorrect, inside the Strip NI Error String VI, and I need a password to get into the diagram for it.

[tst]

It is possible that the connector on the ECDB VI was changed between 6.1 and 7.0. In 7.0, it's an I32 in and a string out. If you have a broken VI with a password, you'll need to remove it or recreate its functionality yourself.

[rolfk]

---

@tst wrote:
It is possible that the connector on the ECDB VI was changed between 6.1 and 7.0. In 7.0, it's an I32 in and a string out. If you have a broken VI with a password, you'll need to remove it or recreate its functionality yourself.

---

This VI is likely calling into a LabVIEW private C API that doesn't exist in LabVIEW 6.0. However this makes me wonder how this Database interface was created. Are you sure it is not just a rip of of the Database Toolkit (which when distributed would mean a copyright infringement)?

Rolf Kalbermatter

Message Edited by rolfk on 07-14-2008 08:08 PM

[tst]

---

rolfk wrote:

Are you sure it is not just a rip of of the Database Toolkit

---

I find it hard to believe that you're not acquainted with the error code database VI. It has the distinction of being one of the most annoying VIs in LabVIEW because almost every time you would search for something and include vi.lib in the search scope, a dialog would pop up asking for its password. This has finally been resolved in one of the recent versions where you can skip all the locked VIs together.

In any case, it's a standard vi.lib VI. I expect that what it does is load the various XML error files and then do a lookup on the code you input to return the description. It does indeed have a DLL call (to a function called GGetOneErrorCode).

[Pablop]

Hello Mike,

It's been a long time since I started using your tool set and it's been smooth sailing. I have a simple application, so once I was able to get going, I moved on. I've been connecting to an Access (mdb) database, that was the example you provided in your written material. However, I need to modify my application to retrieve some from a SQL database located on a different drive, now I'm researching again how to make that connection and of course I'm at a loss to know exactly the best way.

With my existing app I simply issue the connection string "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=\\ServerName\Path\FileName.mdb". If it's an SQL server file, would I use the same thing, as in "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=\\ServerName\Path\FileName.sql"?

Or do I need other "magic words ". 

[Claire_Reid]

Hi Paul,

I don't know much about your application, but I ran across this post and saw that no one had responded...so I thought I would offer some help. I have done some research and have found that ".sql" is a file extension for Structured Query Language Data. So I think you should go ahead and try the format you were suggesting; however, I can not be positive it will work. Let me know how things go.

[Pablop]

Hi Claire,

Actually I've discovered that the file extension for the actual database I'm trying to access is .mdf. I try a simple VI that just makes a connection to that DB using the entire correct path, and I still get the error message, see jpeg.

I think it's either because of access rights, or the structure of the connect string, or both. Unfortunately, I'm not a DB wonk or a driver expert. I can program in LV but anything else I just hack around in. That's why I was hoping to get someone to say "Dude, your supposed to say (fill in the blank), instead of Microsoft.Jet.OLEDB.4.0, duh!"

[Claire_Reid]

Hey Paul,

Here is what I found about this error

"The Microsoft Jet 4.0 OLE DB Provider and ODBC Driver may return the following error message when two executions attempt to gain write access to the same table:

Native error code -2147467259 0x80004005
Microsoft JET Database Engine:
Could not update; currently locked by user 'Admin' on machine 'XXX'.

This problem occurs if each execution or thread opens a unique connection to the database or unique statements to a table, i.e. they do not share handles. The Microsoft Access drivers use a lazy file access method that can easily cause this error. If this error occurs while accessing a Microsoft Access database from multiple processes or different computers, you must attempt to recover from this error and retry the failing database action."