trouble accessing a database in a deployed application

[lmtis]

I am having difficulty accessing a database on a deployed application.  I am using LV2009, and Windows XP.    I am interfacing with the database via ODBC.  The database is located in the "Shared Documents" folder.  I have no problem accessing the database when logged in as the administrator, but when i use the production login I cannot get to it (I can see it in explorer).  I have given the production login administrative privileges and still cannot access it.  I can save a notepad file to that folder when using the production login.  What do I not have set properly in the database setup?

Thanks in advance.

Jim

[tst]

Which DBMS are you using?

Some, such as SQLite, interact directly with a file, but in many, such as SQL Server, the DBMS uses another account to manipulate the actual files where the data is stored. In such systems, you would need to set up the account permissions correctly in the DBMS. You seem to say this is affected by the OS login, so I'm assuming you're using SQL Server with Windows authentication. Is this assumption correct?

[lmtis]

Hey tst,

Thanks for the reply.  I am not sure that I am actually USING a DBMS.  The PC that I am deploying to is not networked, and doesn't have a DBMS installed.  The database was created with MS Access, and copied onto the production PC.  I originally only regestered it as a USER DSN in the ODBC data source administrator.  I have since registered it as a system DSN.  Once I did this, the error changed to that in the attachment.  I opened the file on the PC it was created with, and under security for the users group, all of the access rights boxes were checked.  Right now I am just trying to read the file, and cannot even do that.  As stated in the original post, I can both read and write when logged in as the Admin.

Jim

[rolfk]

It may be as simple as file access restrictions. Under which account did you copy the file to your computer? If it was as administrator it may have gotten assigned the Admin Group and user rights and by that the file might have gotten inaccessible by normal users. Even if you give your user account admin rights (which is a bad idea btw) this user may still not be part of the admin group and as such not have access to files whose owner is set to be admin.

[tst]

When you create a database using Access, the DB backend is a DBMS called Jet which ships with Windows (and isn't a networked DB).

I don't know what causes this, but since the error is an ADO error, you can try doing a Google search on the error to see if other ran into this.

[rolfk]

The only error I can find with this code is     0x800404e4. Failed to retrieve execution context (TLS). This would indicate a problem with thread local storage retrieval, possible in combination with interprocesscommunication between your ADO/ODBC driver and the actual Jet DBMS engine.

however Windows error codes are not that straight forward always. Another possibility would be the WinAPI error 1252 (0x04E4) mapped to a HRESULT error code and this would indicate:

// MessageId: ERROR_OVERRIDE_NOCHANGES
//
// MessageText:
//
//  The group policy framework should call the extension even if there are no changes.

which I have to say does not mean anything to me at all.

[rolfk]

Sorry I got the error code mixed up!

//
// MessageId: DB_E_CANCELED
//
// MessageText:
//
//  Operation was canceled.
//
#define DB_E_CANCELED                    ((HRESULT)0x80040E4EL)

This would indicate that there was some operation like a login dialog or similar that was canceled. It could be that you have assigned a username and passowrd in Access to the database file. In that case you do need to specify the correct username and password in the DSN connection settings otherwise the ADO/ODBC driver wants to prompt you with a dialog for this information, but this has to be enabled with the "prompt? (f)" input to the DB Open Connection method. If that parameter is false, all the ADO library can do is to abort the connection.

[lmtis]

---

  rolfk wrote:
    It may be as simple as file access restrictions. Under which account did you copy the file to your computer? If it was as administrator it may have gotten assigned the Admin Group and user rights and by that the file might have gotten inaccessible by normal users.

---

    It was copied over when I was logged in as Administrator.  I deleted it, logged on to the production login, and replaced the file.  Same results.  Can't open it as production login.

     I downloaded a program called MDB Browser and Editor, and it can open the DB file when logged on as the production user (no longer an Admin).

---

    Even if you give your user account admin rights (which is a bad idea btw)

---

     I agree, giving the production login Admin rpriv. was a troubleshooting step.

    

    On the M$ KB this error is listed as:
    0x80040E4E -2147217842 The change was canceled during notification; no columns are changed

    Which is odd, because I am only trying to read the contents of the DB.

    

    The VI I am using is the exampleVI "Read All Data.vi".

[lmtis]

I still have made no progress on this issue, and just I'd give this thread a bump.  Any help would be GREATLY apreciated .

[Pcorcs]

Hello Jim,

Does the system work correctly when the connection type is configured as a UDL, as opposed to a System DSN or User DSN configuration? The differences in these configurations are outlined here.

To create a UDL (Universal Data Link) for use in Labview, please see the instructions outlined here. 

While UDLs are the recommended connection type for database access in LabVIEW, instructions on DSN connectivity are listed, here. 

Hope this helps progress the troubleshooting process. Please post back any additional updates.

Cheers!