index on question on vfp6 and vfp9 1

[Henry Chen]

i use the same code as below
sele 1
set exclu off
use outa
copy stru to tx3
sele 9
USE tx3
index on dtoc(date)+out_no tag tx3
in vfp6 will not have problem,
but in my vfp9 will have error
file must be opened exclusive
why,
and other people's vfp9 also no error

 

[Mike Lewis]

This is exactly what I would expect.

You have EXCLUSIVE set OFF. So Txt3 is opened in shared mode (not exclusively). But INDEX ON needs exclusive use. That's why you are getting the error. The solution is to open Txt3 exclusively (USE Tx3 EXCLUSIVE).

What I don't know is why you were not getting the error in VFP 6.

mIKE

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

I would also suggest that you stop using numbered work areas in your SELECT commands. These are It is hard to keep track of, and will often lead to errors.

So, instead of:

[tt]SELECT 9
USE Tx3[/tt]

do this:

[tt]USE Tx3 in 0[/tt]

That will open the file in the next available work area. You won't need to know the work area number, and you won't need to worry about keeping track of it. When you want to select the work area, just do [tt]SELECT Tx3[/tt].

Also, you can improve your code by not abbreviating commands to the first four letters. The code will be much more readable if you type the commands in full. For example, [tt]COPY STRUCTURE[/tt] instead of [tt]COPY STRU[/tt]. At worst, it only takes a few moments to type the extra letters, and with Intellisense switched on (in VFP 9), you don't even need to do that.

None of the above is directly related to your question, but by creating good clean code, you make your code easier to understand that thereby reduce the chances of error.

(By the way, welcome to the forum.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Henry Chen]

Thanks Mike,

but it is true, i type the same command in vfp 6 , will not have error,
and my friend's vfp 9 also no error

 

[Mike Lewis]

In VFP 6.0, you can create an index without exclusive use if (i) it is a stand-alone index (an IDX file); or (ii) if it is the first tag in a compound index (CDX). Second and subsequent tags need exclusive use. I don't know if that is still the case in 9.0, but I can't see any reason for it to have changed.

That doesn't explain why you are seeing an error in 9.0. Given that you have only just created Tx3, you would expect this to be the first tag. Either way, you can easily overcome the problem by setting EXCLUSIVE to ON, or by adding the EXCLUSIVE keyword to the USE command. I recommend that you do that, as it is good practice when doing any structural maintenance.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Mike,

I like your signature on message posted today 08:28

Regards,
Koen

 

[Mike Lewis]

Ah, yes, Koen. That would be my playful Caps Lock key.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You can also simply have different settings in the IDE. EXCLUSIVE being ON/OFF will influence what you can easily do as long as you have exclusive access.

But two VFP9 installations don't differ in language capabilities, in one IDE you will have exclusive on in the other not. So that's how two VFP9 installations can easily differ in their behavior if anything is done in exclusive mode or not.

If you make a step from VFP6 to 9 you will discover VFP has become more strict in several ways.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Henry Chen]

but i install foxpro in new computer, and run the same command, don't need exclusive on

 

[Henry Chen]

SAME FOXPRO 9 AND SAME SET EXCLUSIVE OFF, ONE WILL HAVE ERROR, NEW ONE DON'T HAVE

 

[Mike Lewis]

Henry, why do you need EXCLUSIVE to be OFF? You are creating a table, then immediately indexing it. Surely you don't expect multiple users to be sharing the table at the point?

So why not just SET EXCLUSIVE ON before you open the table? Or open it with USE .. EXCLUSIVE? That would solve the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you install new, the default for EXCLUSIVE is ON.

BYe, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Henry Chen]

because this is a program in erp, so i need set exclusive off for multi user use
and i convert from foxpro 2.6
if i need change to use dbf exclusive ,
i need change 1000 program
so the problem is why will have different between new install and old

 

[Henry Chen]

install new, but i set exclusive off
and index on no problem

 

[Mike Lewis]

I understand that the application is multi-user. But I go back to my question. You are creating a table, and then immediately indexing it. At that point, and for that table, why do you need shared access?

Just add the keyword EXCLUSIVE to your USE statement, and the problem will go away. If you later need to share the table, close it and open it again with SHARED.

You only need to do that in one place, and it won't affect any other programs in your application.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Henry Chen]

I HAVE 1000 PROGRAMS HAVE THE SAME ACTION
IF I DON'T SOLVE THIS PROBLEM, I NEED CHANGE 1000 PROGRAM TO ADD USE EXCLUSIVE
MY QUESTION IS WHY ANOTHER COMPUTER FOXPRO DON'T HAVE THIS PROBLEM

 

[Henry Chen]

NOW I TRY DON'T INSTALL SP2, THEN CAN RUN IN FOXPRO WITH NO ERROR
BUT COMPILE TO EXE, EXCUTE THE EXE WILL HAVE THE SAME ERROR

 

[Mike Lewis]

Are you saying that you have 1,000 programs, all containing this same code? One thousand? If that's the case, I would respectfully suggest that there is something seriously wrong with your system's architecture.

And by the way, THERE IS NO NEED TO SHOUT.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

It's the way it is, VFP9 requires exclusive access for indexing. The only way the same code works in VFP9 is when SET('EXCLUSIVE') is 'ON'.

It's clear you SET EXCLUSIVE OFF for shared access, but it's one of the settings specific to sessions. OFF by default in EXE or vfp9r.dll, ON by default in the IDE. The idea behind that difference is the IDE is for developers who need exclusive access more than not and an EXE for multi-users needs shared access.

I can only second the thought of Mike, your architecture is worth rethinking. And since you skip from version 6 to 9 that means you now have to do the work ALL AT ONCE that you could have done gradually over 20 years. I'm not really compassionate about that.

The decision was made to need exclusive access, even for the first index of a CDX, creating it because it's not just a matter of this new file, you also read the DBF while creating the CDX, in the past that could have meant users writing to parts of the DBF already in the CDX will mean the CDX finally created is already out of sync with the DBF. Not in the case of an empty DBF just created, but in case of a large DBF frequently used shared.

Once the CDX already exists and is the main CDX the DBF handling automatically also updates with DBF updates, that's possible in shared mode. That's done the usual way by having a short span of automatic locking as with all write operations. But in that first full table scan of the CDX tag generation process, you process ALL records. And that's better done exclusively for that reason.

That's a not downward compatible change of VFP9. Get over it, there are some such changes and they mean you have to change your code, YES! Absolutely, for the better.

You THINK you've seen a gap in this where the downward compatibility is given, but I'm sure there isn't. You just had cases in which EXCLUSIVE is ON, that's all. SET EXCLUSIVE ON clearly is not your solution, so it is looking for USE after CYOP STRU and making them EXCLUSIVE, Index, then USE the final DBF with CDX shared again and continue. Notice there also is COPY STR WITH CDX now. And even the old way, it is quite impossible you get a problem accessing the newöy created DBF exclusively, as your user session is the only one knowing of it as of now.

Besides, it's questionable an application needs copies if table structures. For the 3GB limit? Or for monthly/yearly data? You could have changed to MSSQL backend over the past 20 years.

Being lazy about something for 20 years means you now have to be busy for a while. What do you do if you have a task that is a dull repetition of work for 1000s of times? You write a program doing that. Source code is text and VFP has string functions. If you don't see it that way, this makes me wonder a bit, but I don't start getting into assumptions.

Even better think of a way not needing all these table copies. It's really a bad construct.

And what's worse is insisting on downward compatibility where there is a good reason for the new rule of the advanced Foxpro language. You go with it.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Dan Olsson]

I have worked with FoxPro over 30 years and I really agree with Mike and Olaf, and it's not really that hard to change 1000 programs with the excellent search-and-replace possibilities in VFP (even in 6).