×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

index on question on vfp6 and vfp9

index on question on vfp6 and vfp9

index on question on vfp6 and vfp9

(OP)
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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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:

SELECT 9
USE Tx3


do this:

USE Tx3 in 0

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 SELECT Tx3.

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, COPY STRUCTURE instead of COPY STRU. 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

RE: index on question on vfp6 and vfp9

(OP)
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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

Mike,

I like your signature on message posted today 08:28

Regards,
Koen

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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

BYe, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: index on question on vfp6 and vfp9

(OP)
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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

(OP)
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

RE: index on question on vfp6 and vfp9

(OP)
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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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

RE: index on question on vfp6 and vfp9

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).

RE: index on question on vfp6 and vfp9

How about a completely different approach:

To create a new temporary table, with the same structure as an existing table, and then to index the temporary table:

CODE -->

SELECT * FROM ExistingTable WHERE .F. INTO CURSOR TempTable READWRITE
SELECT TempTable
INDEX ON TheField TAG TheTag 

Henry, does do what you want?

If so, and if you are now faced with amending 1,000 programs, I can only repeat what we have suggested: write a program to do it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: index on question on vfp6 and vfp9

I imagine this rather being about creating tables per customer or per month, a system you wouldn't need to make that complicated for any reason. For the reason of file size limits? Perhaps in the long run, but not per month. And storing data per customer or client or tenant is also just one aspect of data privacy.

Anyway, if there are 1000s of places something like that is done, a function doing so, of course, doesn't resolve the need to place 1000 calls of the new function. So the burden of this task is much more of an overall deal with never upgrading the VFP version for 20 years and not regularly enhancing and refactoring code making use of new features. Edit: I assume such a system is worked on all the time, I don't assume it is kept as is just because 1999 we already had VFP7 2001, development simply continued with VFP6. But that alone means not profiting of newer features.

There's a term for it: Technical debt. That's more about bad code design, independent on the version of a programming language used, but updates of the language of course play into it, as new language versions give new features leading to shorter easier to maintain code. But at some point, your technical debt either becomes much work that could have been a relaxed side task in the past or even the end of your business.

Assumption: The structural copies of tables vary so much in how they are to be indexed, that he didn't bother writing a function. But COPY STRU WITH CDX or COPY TO WITH CDX actually copy all indexes you already once defined in the original table, so there is no need for individual code when that is the only goal. That means you don't even need individual INDEX ON and you can shrink down much code and replace it with a single line even not writing a function. I'd still do a function, as it would provide a way to centralize the organization of files in folders to just one PRG or even class. That means alone the concept to let a class be responsible for when, how and where tables are copied means you also will only need to change that in one place in the future. A big strategy change could be simply maintaining a directory of empty tables you simple copy per month, the only part of names that will change are then names of the target directory containing the year and month or directories with client names, then your code doesn't even need to copy table structures on the fly and just in time. While just in time solutions can be fine for some problems, if that leads to 1000 places in code you do something, that's not really a good design, is it?

No matter what the detail reasons are, the idea is not just to centralize a "macro" of 5-10 lines to a function, but to consider why you would need something like that scattered at 1000 places in code at all and if this can't be centralised and even done ar application start once per month, for example, for the whole database or folder of tables and not just a single table. A directory of empty indexed tables you only use to copy them for your client/trenent/time period use will be much easier to maintain and your code handling this data will just need to CD into the right directory to work on that data "partition".

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: index on question on vfp6 and vfp9

Hi,
I hate to jump in when two experts are giving already very wise advises.
Why do you create an index with your procedure?
Would it not be simpler to change your dbf and create an index in your table?
Then in you can just

CODE --> vfp

select myTable shared 
set index to myIndex 
Now install Thor with GoFish and all your 1000 codes in your program you can find "index on dtoc(date)+out_no tag tx3' and replace with the simpler version.
One word: DONOT use the Replace function of Thor, repeat DO NOT. Replace all 1000's by hand.
Regards,
Koen

RE: index on question on vfp6 and vfp9

In VFP6 I use this sort of code, tailored for each application to find things:

CODE

PRIVATE m.FLG
SET TALK OFF
SET MEMOWIDTH TO 250
CLOSE ALL
M.PROJNAME = LEFT("EASYWORKS"+SPACE(50),50)
M.PROJDIR = LEFT("D:\DEV\EASYWORKS"+SPACE(50),50)
M.DATADIR = LEFT("c:\FLOWDATA"+SPACE(50),50)
M.DATANAME = LEFT("EASYWORKS"+SPACE(50),50)
M.LOOKFOR	= SPACE(50)
CLEAR
@ 10,10 SAY "Project Main File"
@ 10,30 GET m.PROJNAME PICTURE "@!"
@ 11,10 SAY "Project Directory"
@ 11,30 GET m.PROJDIR PICTURE "@!"
@ 12,10 SAY "Data Directory"
@ 12,30 GET m.DATADIR PICTURE "@!"
@ 13,10 SAY "Database Name"
@ 13,30 GET m.DATANAME PICTURE "@!"
@ 14,10 SAY "Look For"
@ 14,30 GET m.LOOKFOR PICTURE "@!"
READ
CLEAR GETS
@ 16,0 SAY ""
IF LASTKEY() <> 27
	CLOSE ALL
	USE (TRIM(m.PROJDIR)+"\"+TRIM(m.PROJNAME)+".PJX") ALIAS PROJNAME
	GO TOP
	SET ALTE TO D:\DEV\EASYWORKS\REPFILE.TXT
	SET ALTE ON
	DO WHILE .NOT. EOF()
		DO CASE
		CASE TYPE= "K"
			*@ 18,10 SAY PROJNAME.KEY
			SELECT 0
			IF FILE(TRIM(m.PROJDIR)+"\"+TRIM(PROJNAME.KEY)+".SCX")
				USE (TRIM(m.PROJDIR)+"\"+TRIM(PROJNAME.KEY)+".SCX") ALIAS FORMNAME
				DO WHILE .NOT. EOF()
					IF !EMPTY(FORMNAME.METHODS)
						NUMLINES = MEMLINES(FORMNAME.METHODS)
						M.STRING = ""
						M.FLG = .F.
						M.ALIAS = ""
						FOR I = 1 TO NUMLINES
							M.MEMOLINE = MLINE(FORMNAME.METHODS,I)
							IF TRIM(m.LOOKFOR)$UPPER(m.MEMOLINE)
								M.FLG = .T.
								? PROJNAME.KEY ," : " , m.MEMOLINE
							ENDIF
						NEXT
					ENDIF
					SKIP
				ENDDO
				SELECT FORMNAME
				USE
			ENDIF
		ENDCASE
		SELECT PROJNAME
		SKIP
	ENDDO
	SET ALTE OFF
	SET ALTE TO
	SELECT PROJNAME
	USE
ENDIF 

Regards

Griff
Keep Smileing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close