Files in use after creating table and then can't re-run the program after exiting the subroutine.

[A_Radiolog_inFoxPro]

Dear All ,

Its me again , Happy new year.

another issue I am facing is that I create a table and then when the program(subroutine) exists ( returns to the main program ) the table file remains locked. And I can't re-run the software because the file is in use.

my code is as follows.
create table <some directory some name>.dbf (sysmln c(254))
use <some directory some name>.DBF

then the program exists this file <>.dbf is still locked and I can't reuse it and shows an error.

I have no Idea what to do to resolve this,

I tried to add at the end :
FCLOSE ('<>.DBF')
erase <>.DBF
but nothing helped.
I am in no way an expert with foxpro I am just doing my best to optimise it

Thank you in advance

The Idiot

 

[Mike Lewis]

First point is that [tt]FCLOSE ('<>.DBF')[/tt] is not the correct command here. You only use FCLOSE with low-level file access, which is not what you are doing.

The correct way to close a table is with USE. In this case, if the table was named MyFile.DBF, you would close it with [tt]USE IN MyFile[/tt].

Another option would be [tt]CLOSE ALL[/tt], but as the name indicates, that would close every table, not just the one that you want to close.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

First off,

creating a table means you have exclusive access to the file until you close it.

The first question is, whether it really belongs into code to create new tables. A good application uses a database once designed and then populated with data that can have many and very intricately different life cycles, but none that involves creating tables. You create new records.

Many systems do monthly tables, archives, etc. It's a freedom you have, surely, but in the sense of modern databases a database design is something you do once in preparation and then just use it throughout the lifecycle of the software version. An update or upgrade of a software may need a structural extension, but if daily work depends on it, you've experienced something along the lines "fire is hot".

What other's still didn't make clear:

USE is actually a command that serves a workarea, not a table. The most basic USE of a workarea - the USE command without any further options or parameters - is to close what's in it, to NOT use it (so that's unfortunate from the language design perspective). The way you code it, it does the second thing it's meant for, it opens a table. So in short a USE somefile.dbf means a) close what's open in the current workarea and b) open somefile.dbf in it.

In your case it's the same file. And there actually is some sense in it, even though it's the same file name, because when you're currently having SET EXCCLUSIVE OFF that means you close the dbf you have created with exclusive access and reopen it shared.

And now I guess when you do all this in the development environment (IDE) you actually have SET EXCLUSIVE ON, as that's a default setting of VFP itself as the IDE, because as a developer you're usually working in your development version, not productive data, and there you want to get exclusive access to things you act on as the developer (you're the developer in case you work on a program, no matter if it's your profession or not).

It could be the case once you build your code changes and install a new EXE this runs as needed, because within an EXE without any special settings shared and not exclusive is the default.

Again, much talk, but I think you better learn something more than just the direct technical reason. An IDE isn't intended for end users or management. It's for developers. The EXE is for end users including management, usually. And when you need to work in the IDE as manager, you don't become a developer by googling, just like no patient becomes a doctor by googling.

Edit: Since I now know you're at least knowledgeable of VB and professionally a doctor, you know what I mean. The point is, if you'd care about settings you could configure the IDE to be less invasive. For example in this case to use tables shared. You can't prevent the CREATE TABLE to have exclusive access, as that doesn't depend on this setting, but the USE then works in the IDE as it works in an EXE.

Chriss

 

[A_Radiolog_inFoxPro]

Dear All ,

adding USE IN SELECT('<the whole path>') worked. the file closed properly.

Regarding Mr.Lewis
Dear Sir,
I couldn't use close all because it breaks everything else on return to main program.
The USE IN select did the trick.
Thank you

Regarding myearwood Dear Sir, that did the trick just perfect. Thank you

Regarding Dear Mr.Chris Miller.:
Thank you very much for the very detailed and helpful explanation.
I never labeled/called myself a DEV , for my good luck I am a Doctor at profesion and this is a hobby to fix old , forgotten software that no one is willing to fix / optimize / maintain.( devs died , changed professions , retired , got bored etc etc )

Just to give you an idea what I have to deal with.
The code is without ANY COMMENTS. LIke nothing. ZERO.
No documentation from the original DEV of ANY kind.
I was battling to understand what he was even doing. at some parts after several years ( yes years ) of going though his code I got a bit in his head and managed to understand what most things did with some unknown parts that I still haven't touched for good reason. ( because I am not a DEV )

I started implementing patches blindly at the beginning without the use of the debugger( because I was an Idiot).

nevertheless.

I am happy to learn something new every single day.
and I thank you and everyone on this forum for helping me with the stupidly easy questions I have <3 really thank you

Thank you in advance all ,

The Idiot

 

[Chris Miller]

See changes I made to my previous post.

And to add to that: Another point again is, code isn't only code, it depends on further things, in VFP that's mostly environmental settings that have a global effect, so it's good to know all SET commands, especially all related to a data session that aren't really global but have to be set again and again per datasession, when their default doesn't fit our needs. And then as icing on the cake you have to know how defaults differ in IDE and at runtime in an EXE.

In this specific case you could also program more explicit and use the EXCLUSIVE or SHAHED option of the USE command, so generally there are command options (sometimes also parameters of a function call) that can override global settings. But then that forcing of SHARED access is not an option available in CREATE TABLE, as you can only create a table EXCCLUSIVE, even if SET EXCLUSIE is OFF. All in all this is the detail knowledge you can't know even as a general developer, that's not the point. But as a developer you could get to a solution thinking the IDE is meant for a developer and an EXE is meant for a user and settings that influence the behavior of the same code differ in IDE (at design time) and EXE, just like your other thread showed you an expression field1+field2 also can differ in results, because not only the data/variable/field types have an influence but also the length of fields.

So what I'd expect you to know from your VB experience is that code isn't in itself uniquely defining what its effect or result, you always also depend on prerequisites, settings, data scheme definitions etc. So get the idea out of your head that the same code or even the same expressions always have the same result. That's even not true if you could call them deterministic functions. Alone the fact that the + operator means concatenation of strings but summation of numbers makes a difference, and that's not only VFP related. Code is less ambiguous than natural language, but it also depends on context.

You have to know the context, and that's what you're at least very aware of, that you can't know all this just because you developed with any other language already. But not all of this is just lack of specific VFP knowledge, too.

Chriss

 

[Chris Miller]

Actually the only thing that needs to change for the original way to work is SET EXCLUSIVE OFF.

Then the subroutine creating a table and USEing it (by its full file name) is just changing that the table is becoming shared. So the original developer wasn't misunderstanding anything. He was just not working as we're used to work today.

Chriss

 

[A_Radiolog_inFoxPro]

Dear All ,

I think it's all good now , I was trying to erase the file after its use to make sure that it was empty ,

But every time foxpro passes though create table it erases everything SO ... I presume I don't need to do anything.

Thank you very very much for all your help and tips for my situation.

Consider the problem solved.

Thank you in advance

The Idiot

 

[Chris Miller]

It's okay.

He doesn't have to change set exclusive.

Actually it'll work without code change, if compiled as exe runs this with EXCLUSIVE OFF as default.
Then you just have code that blocks you when you run it in the IDE.

That's actually the major point I made about same code different behavior.

Chriss