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 Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Silly question 4

Status
Not open for further replies.
Jan 20, 2007
237
US
Hi everyone,
i was googling for the same question, did not find the answer, so here we go

we use here an application, that was built in VFP 5.0, so tables and indexes were built and can be reindex using the application, but the application itself dos not have the choice to just index a particular table, it has to be all the tables.

anyway i don't have with me anymore VFP 5.0 but i have vfp 9.0 sp2, so here is the question:
if i reindex a vfp 5.0 table that belongs to the application i mentioned before, with vfp 9.0, can this create a problem later for the application as i reindex the table(vesion vfp 5.0) with VFP 9.0 SP2 ?
Thanks in advance


 
Landfla,
(why do you hide behind a pseudo?)
Application was built in VFP5.0. Is it meanwhile transferred to VFP9? If so no problem. If not first transform your app to VFP9SP2 than you can do anything with your tables and indexes as you like.
And if you dont have an app but just using the dbf's in native VFP screen than go ahead with the indexes.
Regards,
Koen
 
You can always backup and try.

Problems I have seen are from changed behavior of functions, VFP7 STR() bug, for example.
But I never used an older version binary to access data created or indexed with a newer VFP version, in the worst case there are changes in the binary structure of the indexes that the VFP5 runtime can't interpret correctly.

But in general you have the key expression definitions in the header of the cdx file and that's it.

If you want to be on the 110% safe side here's what you could do:
1. copy all data shallow, that means via COPY FOR .F., except the one table of interest you want to reindex. Copy that with file copy to have a 1:1 binary copy in VFP5 format.
2. Run the routine, it'll index all tables, but most will have no data and take almost no time to reindex.
3. copy back just the one reindexed table you care about.

Done

Under the assumptions you don't have VFP5, you don't have the source code, just application functionality and features, you can act on the DBFs with your VFP9, you can configure the database path for the VFP5 app. (If not the shallow copy of data, of course, has to switch place with the original data folder, renaming the folder and later rerenaming it does that, no problem).

And then you can get bolder and after a backup you can revert to reindex a dbf with VFP9 and see if the VFP5 app takes it. Just cautious, problems might not show right away. But one thing would work anyway, if you only later find out the CDX gets corrupt because it was reindexed with VFP9, you can take the CDX of a backup, even when it has an earlier state and use the reindex feature of your application to rebuild it, because reindexing just needs the header to be correct, all the CDX tags don't matter, they can become out of sync just like idx and reindexing them rebuilds that, with VFP9 in vfp9 style, with VFP5 or the VFP5 based app in VFP5 style.

You could also check in an example done both ways, if the result is the same with simple 1:1 binary comparison.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Dear Koen,
(why do you hide behind a pseudo?)
Don't know what you meant.

but anyway thanks for your answer.

the APPLICATION i am talking about, was built by someone 20 years ago and it is huge, so having that in mind indexes and tables are still under VFP 5.0,i won't transfer this to VFP 9.0 as it is huge and besides that, all i wanted to know is, if i index or reindex a vfp 5.0 table, with VFP 9.0, if this will cause a problem ? apparently will happen according to Olaf, as actually i see, some str() in the index file example i have this in one of the index file

index on sono+STR(lineno,4)to sono1

so i rather no to screws things up.
Thanks both for the answer
 
(why do you hide behind a pseudo?)
Don't know what you meant.

A little while ago, some of the forum regulars (including Koen and myself) suggested that it would be helpful if forum members used their real names in their posts. This was partly for the sake of openness and transparency, and partly to help people feel part of a community rather than just a group of anonymous posters hiding behind pseudonyms.

This was only a suggestion, and by no means compulsory. But the suggestion was that the more regular members (such as yourself) change their "screen names" to show their actual names. You can do this by going to My Stuff (at the top of the screen) and then My Profile.

Of course, if you have a good reason to remain anonymous, that's fine. There's no pressure. But please at least consider the idea.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Well, VFP7 had a bug about indexes on STR(), as that's fixed this specifically is no problem anymore, but you can have any diffferences in VFP9 vs VFP5 a VFP5 binary can't cope with anymore.

Again, you can try and see where you get the same binary results.
Before reindexing make a backup.
Reindex the file where it is with the app.
Reindex a copy one DBF/CDX of the backup with VFP9
compare the files, simplest test for identical file content is comparing them read in with FILETOSTR() and via == (exact equal comparison).

Bye, Olaf.

Olaf Doschke Software Engineering
 
...oh, and obviously you should also compare the CDX with the original state of the file, because if the reindex had nothing to do, then you don't make a real test case about what the one or other VFP/Runtime version may do differently.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Hi Mike,
My real name is now showing, i never have anyone complaining about it, or at least referring about it, so no problem here we go, my real name, thanks for the clarification as always best rgds.
Thanks Olaf for the whole info as well.
 
Ernesto,

a DBF, inclusive the CDX or IDX files can be opened and worked with VFP9 - no problem. It is NOT advisable to open your DBF's in VFP9 and reuse the same in VFP5.
An application however built under VFP5 cannont be opened in VFP9, you can encounter errors.
If it is that what you want to do, than copy and backup the whole application, and open it in VFP9SP2, see what happens.
Regards,
Koen
 
Hi Koen,
thanks for the advise.
i know i can open any dbf file or even cdx in VFP 9.0 here is the situation again.

SBT PRO 5.0I, it is an accounting application that was written years ago in VFP 5.0 it has all the tools for adding fields to tables and reindexing but if a particular table gets corrupted, i can use VFP 5.0 to select that table in excl mode and reindex it, however i cannot and should not reindex with VFP 9.0 and then trying to use SBT PRO 5.0I with an index file reindexed under vfp 9.0
i am wrong ? please correct me.

If the below needs to be posted in new thread, please let me know thanks.
Note:
also i was able to find the VFP 5.0 CD and install it again in another machine, now the problem is that it does not matter if i installed in win 7 32 bit or win 7 64 bit in xp sp3 compatibility mode, still i am not able to use HELP option from the VFP menu, once i select "Microsoft visual foxpro help topics", the help does not show the content.
it is not imperative to have it but i am sure some fellows here should know why it does not show
Thanks in advance
 
You can try, simply try, you can always return to the backed up files, what hinders you?
Once you know that VFP9 produces binary identical CDXes, you can use VFP9 for reindexing. A file with enough field types or expressions is a sufficient test case. And instead of REINDEX you can PACK, that includes reindexing anyway, as a CDX would not work with changed recnos. A long time ago I showed PACK and REINDEX within VFP9 created same CDX (under now unimportant preconditions). That's not surprising, as in both cases the CDX tree is built from scratch with same data. Data types also didn't change byte positions or byte order big endian vs little endian, what could change between versions is tree structure, index bloat just like memo bloat, and results of functions, so leaf node values. Once you know CDX are exactly the same with a bunch of records and expression and data types you can be very sure there is no difference and then you know you can use VFP9 for PACK and REINDEX.

And why would you need the VFP5 help at all? The VFPX help contains legacy language and up to VFP9. Besides, up to VFP6 VFP was part of the Visual Studio installation and the help was a separate MSDN library setup of Visual Studio.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Guys, the INDEX syntax listed above:

Code:
index on sono+STR(lineno,4)to sono1

Syntax error aside, this will not create a CDX. It will create a standalone IDX. This shouldn't upset an existing application's CDX files. HOWEVER, if the existing application expects IDX files all bets are off.

I'll also point out that the indexing issue with Str() dates back to dBase III and has been "fixed" (and un-fixed) in various versions. Always use all three parameters of Str() in index expressions.
 
Ernesto,
If your, once built exe under VFP5, nowadays runs under VFP9, meaning someone has updated the app, than there is no question. Just reindex under VFP9.
However if your app is still running under VFP5 than I would suggest, backup your tables and reindex with using VFP9SP2, try and if all ok, no problem, if you encounter any errors than reinstall the backup.

Remains: why do the tabels get corrupted and is a reindex ness? That is something you should investigate. And lastly, try to upgrade the whole 'thing' to VFPSP2, should not be to difficult. However please check the results of all the SQL-Select statements.

Regards,

Koen

P.S. If you have troubles / difficulties with updating to VFP9SP2, please contact me, meby I can be of some assistance
 
Hi Koen,
Thanks for the help.
the application always been compiled by VFP 5.0 and if i add some code to it, i just compile it under VFP 5.0, in fact i just added a few things in the past as i have the source code but this application was not written by me.

in order to convert this huge application to VFP9SP2, will take a lot effort, as there are so much code and also lot of customized browse
screen, instance of data created by codes, i assume that maybe not even supported by VFP 9.0 SP2.

Of course i can find each table that are used in the whole application backup them or simply copy them to another location and try to reindex the original tables with VFP 9.0 but then i will need to do this, after hours, as a lot of users are always connected, besides that, i will have to test the application(all modules, like AP,AR,PO GL etc etc..) that really i don't know how to test it as i actually don't use this "accounting application", so what i meant is, i need to know what to do in each module, for example in "GENERAL LEDGER(GL)" to realize if it fails, this is just an example, so of course the best try, it is to have a backup of the original tables, cdx files and so on and try to reindex using vfp 9.0, then open the main application(SBTW.EXE) and see after reindexed under VFP 9.0 if everything is ok but i will need a user that really use all the modules to see if we have any problems.

i copied the other day one of the table in a different folder, then reindexed this table under VFP9.0 ,then i went back to vfp 5.0a as i have this installed as well, then i opened that table from the vfp 5.0 command window and the table opened ok but i only did it with one table, including an str() in one of the idx file, don't know either if this can affect any memo field.
unless i reindex all the tables after i have copied all of them, and then try to open one by one under teh command window in VFP 5.0 if nto problem, then can we say, it is ok ?
if so now i can create my own little script to reindex under a scheduler task
Thanks a lot
 
No, you don't need to use the files with the software modules. And no, just using them won't show yoru problem. But I already told you what to check:

As you also have VFP5 at hand: Copy tables twice, once to REINDEX with VFP5 once to REINDEX with VFP9, then compare the resulting CDX files.

If they are the same, that means if FILETOSTR(".../data/vfp5copy/some.cdx")==FILETOSTR(".../data/vfp9copy/some.cdx"), then VFP9 indexes the same way as VFP9. If that's equal (.T.) you have proof, that VFP9 reindex does nothing different. You can be sure, that this is good news, especially if that is the case for all the CDX files with all the index expressions used and all the values in the tables.

You even already nodded to this, why don't you understand this? If the CDXes end up the same byte for byte all bytes, there is no way this is a difference. VFP9 and VFP5 might still build slightly different index trees, but then not with your expressions and your data types.

Yes, we talked about STR, you have STR expressions used. Well, then test this, so you KNOW and don't need to guess. Dan already added STR() has had its history since VFP3

about one thing you can be sure: It IS surely allowed to reindex with VFP5. If you continue pondering and avoid testing you'll never know. Do it, and you either have 100% certainty it VFP9 has the same result doesn't work, when the files differ are you have high confidence VFP9 and VFP5 index your concrete tables the same way and that's all that matters. If files are same, then there is no question whether VFP5 compiled EXE will fail on them. They are the same files.

If the CDXes after reindexing differ VFP5 could still read them, there are multiple valid ways to distribute nodes in a tree and the tree still works, but you don't have to worry about that at all, if the most outcome is you get same CDX files. And it's not an unlikely outcome. REINDEXINg always means recreating CDX tags, it never changes CDX from the current state, they are rebuilt from scratch, so every record is processed, if the files are same then thousands or hundred thousands or even million of values are processed and you can be extremely sure this wasn't just luck with exactly those records on that order.

If the files differ on the other hand, you also know that you can't use VFP9 to reindex SBT data.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top