SQL database runtime error from certain computers on domain.

Small domain using windows sever 2003,, clients are vista and xp, does not seem to matter operating system, but suddenly my users, who are all local admins, try to access Lytek, a medical billing software that uses SQL, they are getting a runtime error and the program closes.
It's not tied to certain users, but certain machines. Any user that goes to the right machine can login with no problem, but any user that tries to log in with the problem system cannot.
It might also be notable that we have two remote offices that use a vpn connection and then run this program from the server via rdp, they are not able to login with rdp either.
I've compared everything I can between the working systems and the problem systems, but can't seem to find the discrepancy.
This was working fine on all systems until the first of this week, might have started last week.

When you say it doesn't work from a fre days ago I'm thinking maybe some update (either windows update or application update) might have caused the change. Many times I was able to fix some very strange

Your last comment indicates that you may have DNS problems. If you can't login via name you are maybe trying to log on to some different server.

Otherwise, your question is very broad. There may be numberous things (depending on how the program is written) that may cause it to hang or crash. Can you give us the expection text - the message you get when the program crashes.

Exception text is not giving us any information we can use to detect the problem.
As application works when you are not using the admin account - from experience it's probably because
the app is trying to write to some folder on which it has no permission... It doesn't have to be that but I've seen this a lot. Developers too often count on having administrative rights on a PC and don't use the right folders for the task (like %TEMP%)

Try giving users and domain users full control over the application folder and see if that helps. The best way is, of course, to contact the company that made the program and ask then what folder the application uses for work / temp files and give the user running the app full controll on that folder too.

When you ping the server via name, does it show the right IP address ?

Yes, it does show the right ip address.
Problem can't be user rights, as it's specific to workstation.
I have about 5 workstations on the domain, and 2 of them work fine. the other 3 along with the two remote users are unable to access the program, unless I right click and tell it to run as administrator. It doesn't matter what user is logged into the workstation, even if I use the domain admin to login...
So can't be a user rights/permission issue... has to have something to do with the workstations, I'm just not sure what?

If you can run it as admin and not as user, it is exactly the user permissions. There is, without doubt, something configured differently on the PC-s that work from the PC-s that don't work, you have to figure out what it is.

Some questions:
- what operating system are you using on those workstations. If it's Vista or Windows 7 then UAC can be the source of problems.
- These remote users, are they using RDP or is the application locally installed and they connect with VPN to get access to the server ?
- Does the program use an SQL backend on some server ? Maybe it's not accessible from all client machies.

The workstations with problem are both windows xp pro and windows vista business.
All systems were working fine until Wed of last week. Can't find anything to indicate what would have changed that caused it.
As for user permissions, I can log in as any user on the working machines and everything works fine. I can log in as any user on the problem systems, and the only way to access the program is by right clicking and using 'run as admin'
the remote users are using vpn to get into network, then they connect to the server via rdp and run the program directly from the server.
The program does use SQL, and it's the point of accessing sql that we get the error message. You can open the frontend of the program, but when you try to go to file>open menu and log into any of the practices is where the error is generated.

When you say it doesn't work from a fre days ago I'm thinking maybe some update (either windows update or application update) might have caused the change. Many times I was able to fix some very strange problems with system restore....

But the fact the this works when you run as admin is confising me. What was changed... Do you use domain account to access the SQL database ? Maybe that's the difference - if some users use domain accounts to access the database and others maybe use SQL authentication, so ones work and other don't. I'm just thinking out loud.

When you login to your server via RDP, does it work with user accounts or does it only work with admin account ?

Does this application use an ODBC connection to the SQL server in order to access the database? If so, I would check the ODBC set up on those machines that are having the problem. Run through the config steps for the ODBC connection and at the end make sure that that the connection test runs successfully.

Ok, not sure how to handle this, I'm appreciative of the help, and open to suggestions/comments for point assignment. Read below for the, I won't call it a solution, but perhaps identification of the culprits.

The problem as lucius pointed out, was caused by a windows update. Not even sure which one. But basically, the update broke something in UAC. Windows xp machines weren't affected, as I erroneously reported at first. The solution to the problem was to turn off UAC on the Windows Vista machines, this allowed the users to access the program and files.
Problem is still unresolved on the two users who RDP into the server. If we disable UAC on the server the problem remains... if we enable UAC and make the users Administrators on the server, the problem remains... If we both, disable UAC and make the remote users admins on the server the problem is no longer. But for obvious reasons this is not a viable option. I can't have a couple of remote users being admins on my server nor is it something I want to disable UAC on either.
The problem is only affecting one major piece of medical billing software, but the medical part brings all sorts of HIPAA concerns with it as well. We've involved the software manufacturer in the process, and maybe it will get resolved.
I don't know if this question has any value for the PAQ, or how to distribute points if it does. So I'm open to suggestions and/or comments?

As I commented before - if admins can use the software and normal users can't, the problem is with permissions. These can be either NTFS permissions - the user has no permission to write to some location the app is trying to write to, or registry permissions,or any kind of other permissions an application may have towards a system. Only application manufacturer can know this, so it's good to have them involved as they should be able to sort this out.

You could also "monitor" what the application does. What paths it uses, what registry keys and what files it touches when running under admin user. You would then know what the application does and at what point the app does something that a normal user has no access to. This is all the application developer needs to solve the problem.

Unfortunately I didn't use such monitoring tools for quite a while, so I can't suggest directly. I remember there were some programs that did exactly that and were used to completely uninstall programs. Quick search on Google says that Process Monitor can do this (has RegMon and FileMon in it).

Introduction
Since I wrote the original article about Handling Date and Time in PHP and MySQL (http://www.experts-exchange.com/articles/201/Handling-Date-and-Time-in-PHP-and-MySQL.html) several years ago, it seemed like now was a good time to updat…

Does the idea of dealing with bits scare or confuse you? Does it seem like a waste of time in an age where we all have terabytes of storage? If so, you're missing out on one of the core tools in every professional programmer's toolbox. Learn how to …