Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

File is in use

Status
Not open for further replies.

alisaif

ISP
Apr 6, 2013
418
AE
Hi

I am using the following to save records in a table:

Code:
If Used('PrnJobMain')
   Select prnjobmain
   Set Order To jono
Else
   Use prnjobmain In 0 Shared AGAIN 
Endif

But the subject message is irritating me. How to get rid of this?

Thanks

Saif
 
This is probably happening because the table is open in another work area. That in turn is probably because of your use of the AGAIN clause. It would be better if you did this:

Code:
IF NOT USED('PrnJobMain')
  USE PrnJobMain IN 0
ENDIF
SELECT PrnJobMain
SET ORDER TO Jono

That way, you'll only get one isntance of the table, and the error shouldn't arise.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Thanks it works.

But can I find in which work area it is open?

Saif
 
But can I find in which work area it is open?

In the Development Environment, you can open the Data Session window. To do so, select Data Session from the Window menu; or click the Data Session toolbar button; or type SET in the command window. The Data Session window shows the aliases of all open tables, with their work area numbers.

Alternatively, call the AUSED() function to get a list of the aliases and work area numbers.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
We've already had this not long ago. But your code should now work.
Which line really errors? Use prnjobmain In 0 Shared AGAIN?

1. You checked the alias is not used, so USE prnjobmain without ALIAS clause will open it as alias prnjobmain.
2. the prnjobmain.dbf might be used, but you use it with AGAIN - this has to work.

Overall: The alias is not used and the file may be used with different alias, but due to using it AGAIN, that won't matter.
To get this error for this line, there would need to be something, which opens the table, but even if that was the case, the table would jsut be used with an alias like B,C,D, a letter corresponding to the workarea number.

So as said, this should never error. Are you sure this is the code erroring and not some other table opening? Do you have an error handler telling you LINE() and PROGRAM() of the error?
Or vice versa, set a break point at the line and step through it to see it happening there.

What you could do is add an alert, if the alias name prnjobmain is not in use after opening the table again:
Code:
If Used('PrnJobMain')
   Select prnjobmain
   Set Order To jono
Else
   Use prnjobmain in 0 Shared AGAIN [b]ORDER TAG jono[/b]
Endif
[b]Assert used('prnjobmain') Message 'prnjobmain.dbf was not opened with alias prnjobmain'[/b]

But even if that is the case you would get the error file is in use in the next run, you would also have all kinds of problems in following code, as you expect you can work with the alias prnjobmain.
Just one thing about this: Asserts and break points and other debugging stuff does not work in the final EXE, only in testing code within VFP.

One other thing is good to know: If you USE some.dbf IN 0 you open the dbf in an empty workarea, but the selected workarea is not the opened table, it's still the workarea selected before the use. If you want to know tha lias name used by USE you do this in two steps instead: 1. SELECT 0, which selects an empty workarea, 2. USE some.dbf (with any further options). The USE will be done in the empty workarea you selected in step 1 and so the workarea will be selected and ALIAS() will tell you the alias name it has got and DBF() will tell you whether it's the DBF file you wanted to open.

Bye, Olaf.
 
Hi,

In the Development Environment, you can open the Data Session window. To do so, select Data Session from the Window menu;

I checked using data session windows and I found that some tables are open in session1 and few are in session2.

In form I kept the datasession=2 but why few tables are open in datasession=1.

Please guide..

Thanks

Saif
 
These might be tables that you opened yourself (either with USE or by way of a form's data environment).

Or they might be tables that VFP opened behind the scenes. For example, if you run a SELECT on a table that is not open, then VFP will open the table - and leave it open, even after you close the cursor generated by the SELECT.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Yes, I am using no. of select statement, so how to combat this problem?

Saif
 
Why is it a problem? Provided you always check to see if a table is open before you explicitly open it (using the code I showed you), there should be no difficulty. Why are you concerned about this?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
>In form I kept the datasession=2 but why few tables are open in datasession=1.

Form.Datasession is not the same as a datasession id. Not at all.
Read the help:
If all your forms have datasession=2, they all will generate a new datasession id, a private datasession.
But anything you do outside of forms will not put its result in the form datasession.
Aynthing you do in main.prg before even starting the first form.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top