Type mismatch error in executable but not through Visual studio

Hi all

I am currently working on a relatively complex 2-tier Visual basic project (using an AS400/DB2 database), on which I have encountered the following interesting but strange problem. One of the features of the program doesn’t work in the executable when the executable is run on a computer without VB6/Visual Studio installed, but it runs without any problems on any computer that has VB6/Visual Studio installed.

To be more exact the error appears when a button is pressed that loads a form that contains a normal textbox and a multiline textbox. This form directly reflects a record from a table in the Database. If the form is opened in new mode (i.e. a corresponding record doesn’t exist in DB) the user is able to paste/type any text in the multiline textbox. When he presses the save button a record is inserted in the database. Then the user is able to edit that record. The error message (error 13, type mismatch) appears at exactly that point i.e. when the system tries to load and assign the text (it is a varchar field of about 10000 characters) in the multiline text box.

For all database operations the program uses well-tested libraries, implemented through visual basic 6 classes. The libraries are in that system for more than a year now and they have been used successfully in similar situations (i.e. multiline textboxes).

Another fact might be important is that the system is consisted of three visual basic 6 projects. One executable and two DLLs. The problem appears in one of the two DLLs, actually the most complicated and big one of the two.

The exact source code line at which this problem appears cannot easily be determined because the error doesn’t appear when it is run through visual studio debugger since visual studio is installed on that computer. I have also checked the text that was put for any strange characters but it seems to contain only ASCII characters

Does anyone have any explanations/ideas how to fix it? I have started putting msgboxes at various places in the flow of the program but it is a very difficult hard since it takes approximately an hour to compile . Is anyone aware of any tools that will help me debug the runtime executable?

Thanks,

Thomas

can you isolate the problem into a stripped down executable which compiles quicker? - while you debug

I am already in the process of doing that. Unfortunately, I can't recreate the problem in the development, test environment and so I have to go the clients side (production environment) in order to perform these tests something that is not as easy as it sounds (my client is at a different town than my office).

Of course this doesn't guranteed that the problem will persist in the stripted version....but this is anyway the best option I have so far.

Thanks
Thomas

You may get type mismatch errors such as this if you dev/compile on a system that is running different versions of some common type libraries. It may be worth checking the versions running on the client's system. I have had this problem (though with SQL Server/ADO) which was resolved by updating some standard libraries.

HTH.

Do you have a pretty good idea where in your code the error happens? You could add some "app.logevent" statements around some of the lines of code you believe may be causing the error, then check the computer's application log for your messages.

MrTed is right about version issues; they can be a real problem when installing on a new system. You could check the versions of the .dll's listed in your setup.lst file against those on the target machine.

Hi all,

Sorry for not posting earlier but I have been away.

I have performed the following small experiment taking into account what some of you have said:

1. I created a light version of the project with only the forms/classes/modules that are needed to reach the point where I get the error. I recombiled it and re-create the package.

I then completely removed the previous executable from a target computer and install this lightwieght version.

The good news is that the problem did not appeared, which most probably means that this is due to different dll versions. The bad news is that I can not be 100% sure that this is the case until i re-create the package of the whole program.

This is not very easy to do (not for technical reasons) but when I do it, I will post the results here, to continue discussion or simply let everyone to know that this was the reason 100%.

Thank you to all of you that helped in one way or another.

Thomas