Slightly Odd Behavior

Hello.

This is rather a difficult question to ask.  Basically we have an application we created.  With this application it asks for a user id and password, the script confirms it and then opens a form.  All this works wonderful on all machines.

Then one day we decide to add some code deeper in the program.  Now on two machines it asks for the user id and password and just hangs.  On all other machines it works fine.  We did not touch the code that has to do with the log on.

The program was written in VB 6.0 and is run on NT workstations without VB installed.  As I said, it worked fine until this change was made.

We have reinstalled the application still to no avail.  Does anybody at all have any ideas?

I know this one is difficult.

Thanks,

nnaxor
LVL 1
nnaxorAsked:
Who is Participating?
 
Guy Hengel [angelIII / a3]Connect With a Mentor Billing EngineerCommented:
You should add some debugging code to the application, to follow what happens.
If you can access the PC's where the problem occurs with not problem, I would suggest to use message boxes, but what i would do is this:

Public Sub EnterFunction (fName as string)
open app.path & "\debugging.log" for output as #1
print #1, fname & vbtab & "Entering"
close #1
End Sub

Public Sub ExitFunction (fName as string)
open app.path & "\debugging.log" for output as #1
print #1, fname & vbtab & "Exiting"
close #1
End Sub

Then, for all your (relevant) functions, add the EnterFunction at the beginning and the Exitfunction at the end of the Sub/Function ...

I Would put the above code even in a standard module, and include a flag which could be set at startup:


Public Sub Main ()
  If Command$ like "*/DEBUGGING* then
    blnDebugging = true
  end if
  ...
 
End Sub

and check that flag in the EnterFunction and ExitFunction before writing to the file.

With the output of this file, you can see in which function the problem occurs.


Now, I guess that the problem is an errorhandler that has runs into an error and calls itself...

CHeers
0
 
Julian_KCommented:
Well... remove all "On Error" statements and check where it hangs ;-)

I suggest you writing a small DLL for run-time logging.
The easiest way is to open a text file and in the beginning of each procedure/function to write to this file the name (eventually the parameters).
When the program hangs, you can view the text file and get more info on where exactly it hangs, and what parameters were recieved, etc. It's not a lot of work.
0
 
nnaxorAuthor Commented:
That makes sense and seems like a good idea, however, the problem we have is that it only happens on two machines.  The other dozen or so it works fine on.  This would seem more like a machine related problem rather then the program.  Unless I am missing something.  Because it was working on those machines before.  It is on a network drive and we actually install the app on those pcs.  I'm not sure how debugging on a single machine will make any difference.
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

 
Julian_KCommented:
angelIII, you're faster :-)
0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
Debugging will SHOW you the difference you can't see right now. It will tell you in which procedure the code hangs -> you will only have few lines to read and try to imagine what the problem could be. Something HAS changed, you don't know -> You DEBUG !!!
CHeers
0
 
nnaxorAuthor Commented:
That makes sense and seems like a good idea, however, the problem we have is that it only happens on two machines.  The other dozen or so it works fine on.  This would seem more like a machine related problem rather then the program.  Unless I am missing something.  Because it was working on those machines before.  It is on a network drive and we actually install the app on those pcs.  I'm not sure how debugging on a single machine will make any difference.
0
 
nnaxorAuthor Commented:
Sorry about the double post.  You are both entirely correct.  The machines that are not working are not close by and so before beginning the trek there I wanted to confirm there was nothing else it could be.  As it seemed machine related.  We will do as suggested as soon as we can get to those machines.  Thanks much and let's hope this helps.
0
 
nnaxorAuthor Commented:
BINGO - you guys so rule - no wonder it is called experts-exchange <grin>.

Okay now we get an error:

430 Class does not support Automation or does not support expected interface.

Angellll?
0
 
nnaxorAuthor Commented:
Thanks much.  As this helped to diagnois so we could find the problem, I will go ahead and close out this question and start another one now that I know what the problem is.
0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
Hi,
Glad we could help you by pushing you :-)

430: you probably have
* a binary installed that is not installed with the correct version

When you know on which line the error occurs, you know the class that it expects, and compare the version of the development PC with the one on the PC where the problem occurs.

CHeers
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.