Cant import anymore on Windows 7

[TKyte]

I have a problem that just started.
I am using Visual Foxpro 9 on Windows 7 64 bit and it has worked fine up until just recently.
When I try to import from a older foxbase database i get an error after it imports a few tables that the "File is in use" but it actually isnt.
Then I click ok and I get an error "Variable "DNAME" is not found."
This has worked fine with Vista 64 bit and with Win 764 bit up till now.
Any idea what is causing this or what I can do to fix it?
Thanks...

Ted

 

[thegame8311]

you don't have the tables, database or project open anyway at the same time correct?

 

[Koen Piller]

TKyte,
a little bit difficult to answer without any code. I would suggest first you use the debugger, so you invoke in your programm:

On Error SET step on

now when the debugger starts, due to the error "File is in use" you select in the debugger menu Window ->Call stack and you look for the window causing the error, if you now open that file you can find the code row causing the problem. Either that enlightens you straight away, o.w. you shall have to rerun but stop each time you run this line and examine the variables.
Much, much bettter, ofcourse is to built an errorhandler which will give you all the info why the error occurs.
Jockey(2)

 

[TKyte]

That is correct Jockey2.
I copy the files from another machine to do the import.
The foxpro file is a compiled .exe and has been working fine on the same machine is the mystery.

Thanks...Ted

 

[TKyte]

Sorry that was for thegame8311.

Ted

 

[TKyte]

Thanks Jockey2 I will try that and see what happens.

Ted

 

[Dan Freeman]

What do you mean by import? Into what?

A Foxpro program does not need to "import" Foxpro data. It can be used directly.

What command(s) is(are) failing?

 

[JRB-Bldr]

it has worked fine up until just recently.

That understanding is a good place to begin.

Now for the 'standard' follow-up question when this is the situation....

What Changed?
Changed anywhere in the system - workstation virus checker, OS, server environment, etc.

Before we even try to get the details on what you mean by 'import' and from where, we should understand the changes that have occurred somewhere in your over-all system.

More often than not, whatever changed introduced the problem.
Find it and you are most of the way (if not all of the way) to a resolution.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Obviously the variable component here is the data to import, isn't it?

Looks like your exe doesn't like the structure of the new data, eg a field dname is missing. Might also simply be a table corruption of the database/tables you import to.

Just because software is soft, doesn't mean it can't break, and that happens instantly, a table header is not degrading in time, it breaks at one instance, same goes for index etc.

Check your database, perhaps.

Bye, Olaf.

 

[Mike Lewis]

Hi Ted,

To go back to your original question, you say you get a "File is in use" error, but the file in question is not in use.

Are you sure about that? Often, VFP will open a table behind the scenes - and leave it open - without your knowing about it. This happens, for example, in a SQL command.

To check that, run the application in the development environment. When the error comes up, suspend the program, then look in the Data Session window. Use the drop-down at the top of the window to select each data session in turn. In each case, check the list of open files in the main part of the window.

One other possibility is that you have fallen foul of something called opportunistic locking. That's a lot more complicated to explain, and more difficult to deal with. Let's come back to that if we can't find an easier solution.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[TKyte]

Thanks guys...
I am leaning on the side of something else in the system is causing it as it just started.
Because I dont use it a lot I cant really pin point what changes to the system could have done it.
The other idea of the file being corrupt is another possibility as well. I will see if I have some older files to test.
I will check these out first.

Thanks again...

Ted

 

[Dan Freeman]

Obviously the variable component here is the data to import, isn't it?

That's why I asked for specifics on what's being imported.

This edges toward being the first time someone provides an XLSX where an XLS is expected, but without details I wasn't going there.