Program works fine in 1 computer but not in other one??

[Olimits7]

Hi,

I have a VFP program that I use to manage my website orders on the backend. I'm currently having my programmer make some changes to fix some errors/issues that I see when I use this program.

However, this is the weird part on his computer all the issues that he fixed work fine (he sent me screenshots to show me), but then when he sends me the source files he updated and I try to build the *.exe I still get the same issues I had before on my computer. Can somebody point me in the right direction to why this is happening??

I don't understand this is we both have the same exact source code files to build the *.exe.

Just so you know what some of the errors he fixed are I would get "Variable" missing message on 1 of the screens, on my packing slip the order # doesn't show on one section of the packing slip, I get a "Data Type Mismatch" error, etc...

Some things that we have tried to figure out why this is happening is:

1. He sent me all his files and I built the *.exe on my computer but that did't work.
2. He sent me his *.exe that works properly on his computer, but it didn't work on my computer.
3. I sent him all my files and when he builds the *.exe on his computer the issues aren't there anymore and everything works properly.

I don't understand why this is happening since we both are running Windows XP Professional w/ SP2, and we both have VFP 9 SP2 installed on our computers.

Could this be an issue with VFP 9? or the runtime files?

Thank you,

olimits7

 

[audiopro]

Hard to say without examples of code which is failing.
If you are getting variable type mismatches when trying to write to a table, it is possible that the 2 tables are different in some way. eg. a field in your table is set to text the same field in his table is set to numeric. Just a stab in the dark but you need to narrow down the error to a section of code.


Keith

http://www.studiosoft.co.uk

 

[Olimits7]

Hi,

We are even using the same *.dbf files; this is what's so strange about this. I sent him all my *.dbf files and on his computer everything in the *.exe works properly...strange!!

Thank you,

olimits7

 

[Olaf Doschke]

Maybe it has nothing to do with source files and the exe but the backend database.

For example the error "variable ... not found" can be caused by a missing table field, as foxpro can acess both variables and fields by a name expression and finally thinks a variable was meant as it didn't find a field of that name.

Surely the error is caused by something you did not exchange with each other but which is nevetheless part of the whle application running.

It helps much to have an error handler loggin the error and the module and line it happened. VFP help has such a global error handler in it's sample code of ON ERROR.

Bye, Olaf.

 

[audiopro]

Did your programmer originally experience the same errors as you and then fixed them. If so, the method he used should give the information you need to fix it.

Keith

http://www.studiosoft.co.uk

 

[cricket]

Check your file locations.
You may be recompiling previous versions.
Why not have your programmer do the compile to EXE, and see if the problems persist?

 

[CajunCenturion]

It could also be that he is using some objects external to VFP that are defined on his machine but not yours, or are disabled on your machine. For example, if he's using the Regular Expression object from the Windows scripting engine and you have scripting turned off, it would work on his machine, but not yours.


--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Mike Lewis]

As well as EXE files and DBFs, there are many other things that could cause differences on the two systems.

One or two that come to mind:

- Presence or absence of a Config file (usually CONFIG.FPW).

- Different shortcut used to launch the app (might include a command-line switch which affects the behaviour).

- Registry entries.

- Other configuration or settings files, such as INI files, MEM files, etc.

Perhaps the best thing the programmer can do is to install a proper error-handler. This should trap the error and save as much information as possible about the environment at the moment the error occurred. It's hard to track these things down without that sort of information.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Olimits7]

Hi,

Thank you for your replies.

My programmer wanted me to mention that the packing slip error that I wrote about above appears in report form not in code source.

MikeLewis, do you have any recommendations on a proper error-handler software I can tell my programmer to download to test what you wrote out??

Thank you,

olimits7

 

[Mike Lewis]

the packing slip error that I wrote about above appears in report form not in code source.

In which case, the obvious question is: Are you sure you have the same version of the report? Reports are held in a pair of files, with extensions FRX and FRT. These files might be "bouind in" to the executable (i.e. not distributed as free-standing files), in which case this won't be relevant. But if the files do exist separately, you need to make sure you both have the same versions.

do you have any recommendations on a proper error-handler software I can tell my programmer to download to test what you wrote out??

An error-handler isn't a piece of software that you can download. It's code that the programmer must write as part of the application. There are probably some examples that can be downloaded, but, to be honest, if the programmer doesn't know how to write an error-handler, he probably won't understand the examples.

That said, you might tell him to read about ON ERROR in the VFP Help. But I would check the report version numbers as your next step.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

Reading your description, I'm most suspicious that you're not really running the new code you think you are. Have your programmer add a WAIT WINDOW or MESSAGEBOX() right at the beginning of the application with a message indicating that you're in the new version, and try running that. If the message appears, you'll know you're running the code you think you are. If not, you have some kind of path problem.

Tamar

 

[Olaf Doschke]

My programmer wanted me to mention that the packing slip error that I wrote about above appears in report form not in code source.

A report still can have source code, it's just a special file type, but it has a data environment, where there can be code.

I still think the issue is a difference in some table with a field missing with that name that is reported to be missing as variable. If you localized the error happens in a report it could likely be some table the report is related to.

To expand about why a missing field in a table can lead to a message "variable ... not found":

If for example an expression of a report field is simply: firstname

Then vfp determines if this expression is a field name or variable name. It first examines the table, that is open in the current workare, if it has a fiel name "firstname". If not, vfp continues to search for a variable named "firstname". And if it doesn't find that it reports the error "variable firstname is missing".

The reason could be the field is missing from the table the rerport runs on, or the table is not selected in the active workarea.

Do you have a grid on the form, from where you start the report of? Does the error occur, if you set focus to some other control on the form, a textbox for example?

does the report run on the table that is displayed in the grid or does it run on a different one?

Bye, Olaf.