05-14-2012 01:06 PM
05-14-2012 01:29 PM
Trouble is I've distributed a standalone app that retrieves infro from the local ACT database using a OleDbConnection and a SQL statement using the .pad file for connection.
The standalone app requires that act be installed(to have all the proper assemblies present) but it doesn't require that
ACT be running at the time.
Does the error originate from the machine my app is running on, or the server that hosts the database?
Any suggestions here?
05-14-2012 01:51 PM
05-14-2012 02:55 PM
Think I'm out of luck.
1) the users don't have admin rights
2) even if they did, the users shortcuts are to specific .pad files so they directly open the desired database (no 'RUN AS' option present on the shortcuts)
3) IThe 'RUN AS' option isn't persistent.
I can't tell all users here's the admin password and everytime you run ACT you must RUN AS.
05-14-2012 06:26 PM
1) As a test if you run ACT as administrator does the error still appear?
2) You can set the associated EXE to always run as admin. Please see #3
3) You can set any exe to be persistent. Right-click on the exe and select 'properties'
Select the 'Compatibility' tab then place a check mark in the Privilege level' to "Run this program as an administrator"
As a test, right-click and select "Ran as admin.." does the error still persists when running ACT under the admin role?
-- Jim Durkin
05-16-2012 09:01 AM
Good info. I was unaware of the persistent option.
I've setup a test workstation and automated some repetitive db connections to see if this solves it. Only time will tell.
There error is elusive & I can't produce it on demand.
Many Thanks for your insight.
05-18-2012 10:37 AM
This may just be our environment of Windows 7 but each time the sage .exe is run, it prompts for an admin user & password. That it's to run with admin rights is persistent, but the credentials can't be saved.
I can't distribute an admin password to all users so no joy.
It does work 99% of the time, so all's not lost.
05-24-2012 05:33 AM
I've had a bit of a "left-field" idea on this possibly. Are the user logons shared at all between user's or are there multiple OLEDB connection calls possibly by any one user?
I don't really know how the OLEDB connection works but could it be that it only allows a single OLEDB connection instance per call and if you have >1 the connection/permission fails?
05-25-2012 11:38 AM
User logons are not shared ever but you maybe onto something.
Many of my aps that experience this error do make multiple OLDB calls.
Get some data from act via OLEDB->get some user input-> get more info from act via OLEDB
It's rare that the first OLEDB call fails.
I wonder if sometimes the connection isn't closed and subsequent calls fail?
I can explore that. Thanks!