App Only Runs Under Admin Account

[lucyv]

I've written a VB6 app for my work. Everything works fine on my developing & testing machines, but I can't seem to run the app on other workstations. The app seems to load fine but does not show certain forms. But when I log into the workstation under the Admin account everything works fine.

Does anyone know how I can fix this? Do I need to give certain permissions/rights to some files or folders?

Thanks in advance,

-lucyv

 

[BobRodes]

<does not show certain forms

Can you expand on this?

Bob

 

[gmmastros]

If the app loads but does not open certain forms, I would check to see what those forms are doing. Are they looking for files in a folder? If yes, then you'll need permissions to the folder. Are the forms checking registry information, you'll need permissions for that also.


-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[lucyv]

My application is loaded using Sub Main, which in return loads the application's main form (a MDI window). The app then connects to a SQL Server database and then loads a login screen to allow for the user to log in. However, the login screen never gets loaded.

I've given the local user account full access to the directory where the application resides as well as read/write access to the registry.

As I noted earlier, the app works under the Admin account but not under the local account.

-lucyv

 

[gmmastros]

You connect to a SQL Server database and then show the form?

What type of authentication are you using for SQL Server? Integrated Security? Are there SQL Server error messages that you are not displaying?

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[lucyv]

No, I am not using integrated security. The server has its own user account in which the app uses to connect.

I also have a global error handling routine that handles all known & unknown errors. If an unexpected error is generated the app will display the error number, message & location to the user and then log it into the database. But no error messages are being generated.

-lucyv

 

[gmmastros]

Let me get this straight.

1. Your MDI parent form displays.
2. You connect to SQL Server using SQL Authentication.
3. You display a log in form.

Since you are connecting to the database before showing the login form, you must be hardcoding the username and password. Is this correct? What does the connection string look like? Feel free to change the relevant info contained within the connection string.

As a debugging step, I recommend you try creating and ODBC connection to the SQL Server. It may shed some light on the problem.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[lucyv]

No, I am not hardcoding the username & password. The first time the app runs it looks for certain information from the registry (server name, database name, etc). If the information is missing then the application will prompt for the information & allow the user (myself) to key in the database & server information.

-lucyv

 

[gmmastros]

Do the non-admin people have access to the registry keys that you are using?

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[lucyv]

Yes, I made sure they have access to the registry.

-lucyv

 

[strongm]

Which bit of the registry?

 

[lucyv]

HKEY_LOCAL_MACHINE\Software\{app name}

- where {app name} is the name of my application.

 

[gmmastros]

Try this...

First, log in to a machine with admin priveleges. Click Start->Run, type regedit. Browse to that part of the registry. Right click the {app name} key and click export. Save the registry to a file on the local hard drive.

Then, log in to the computer with regular/non-admin rights. Browse to the .reg file you created and double click on it.

I suspect you'll get a message claiming not to have access to the registry key.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[lucyv]

I did this but it can up fine. I have full access to the registry. Weird???

-lucyv

 

[gmmastros]

Hmmmmm.... Yeah, something weird is going on.

Obviously, something is silently failing. The only other suggestion I have for you is to insert a bunch of debug code. I hate to do this because sometimes you miss the debug code when you remove it.

In your Sub Main, put a couple msgbox commands, like....

Msgbox "Starting Sub Main"
Msgbox "Loading MDI Form"
Msgbox "Ending Sub Main"

In your MDI Form, put more message boxes.

MsgBox "Starting MDI Form"
Msgbox "Doing This"
Msgbox "Doing That"
.
.
.
Msgbox "Ending MDI Form Load"

compile, then run the app. Take note of the msgboxes as they appear. At some point, you should be able to narrow down the problem. Unfortunately, this is a slow process. Hope it helps.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[lucyv]

Yeah, I was already doing that. I'm going to have to put a ton of message boxes to show me what's executing and what isn't. Unfortunatly the problem is happening at one of our remote sites so I'm going to have to a trip.

*Tip, when I'm debugging I using place message boxes with the keyword "todo:" in it. For example, Call Msgbox("todo: starting sub main..."). When I'm done debugging I search for all "todo:" and remove them when I don't need them anymore.

Thanks for your help George. I'll keep you informed on this issue.

-lucyv

 

[gmmastros]

The ToDo: method is a pretty good tip. What I usually do it to add a global called globalDebug As Boolean

Then, in your Sub Main, you can check for a command line argument.

Sub Main

dim cCommand as String

cCommand = Command
If Instr(cCommand, "/Debug") > 0 Then
globalDebug = True
Else
globalDebug = False
End If

[More lines]
End Sub

Then, I put code in places like....

If globalDebug Then MsgBox "Got Here"

Then, all you have to do is start your app with a command line argument of /Debug and you will see the messages. Without the command line argument, no messages.

Of course, you could remove the debug code later, but leaving it in isn't so bad either because you are only checking the status of a boolean which won't hurt execution speed even if you forget to remove it.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[strongm]

Alternatively, something like:

Option Explicit

#Const DebugMode = True

Private Sub Command1_Click()
#If DebugMode = True Then
MsgBox "todo:"
#End If
End Sub

And now all you have to do is change the definition of the Const to make the Msgbox disappear (and not get compiled)

 

[lucyv]

George, that's a pretty good tip also. My code would be longer, but I can see how that would be effective.

Strongm, I just learned this in VB.NET (I didn't know it could be done in VB6). Thanks.

-lucyv

 

[BobRodes]

Strongm's is considered best practice, in light of the fact that the code contained in the #if statement isn't included in the compiled code if the statement is false.

Lucy, let me see if I understand what you're saying. Your application's intended behavior includes: in Sub Main, check the registry for db values. If they don't exist, open a login screen. Write the captured values to the registry. Once the values do exist, open a connection to the db.

As such, are you saying that the login screen is never supposed to display after the first time?

Another question: have you disabled your error handler and verified that no errors are generated?

Bob