Reattach CDX files?

[DaveL]

Is there an easy way to reattach CDX files to the free tables in my database?

I am trying to convert the data from the tables in a previous version of our application into the newly formatted tables in our new application. What I have done is copied the DBF files from the old application database into a new project (working area) without the CDX files. I made changes to the tables in the working area by adding and deleting fields, and applied some data conversion programs, all while there were no CDX files in the working area project. Now I am trying to copy/replace the converted tables into the new application database that already has the CDX files in it.

I am sure I am missing a concept. Can anyone give me any ideas what I am missing and how I might solve this problem?

Thanks!

 

[DSummZZZ]

Why not open the old tables, see what the tags were/are, and create new ones for the new tables?

Dave S.

 

[RedLion]

When the tables have the same structure and name as the copied ones, you can open the tables one for one, and requery them, so the indexes will be uptodate again.

Charl

 

[rgbean]

One thing that would help is to clarify whether these tables are "free" or part of a database. If they are truely free, and the fields you changed weren't involved with any of the indexes, then it could be as simple as using a hexeditor to flip a bit in the .DBF's header. (Although, you'd need to do a REINDEX to get the proper links for the records you've ended up with.)

If the tables are actually part of a database (.DBC), then you'll need to recreate the indexes. If you got a working database, it's as simple as running GENDBC.PRG against the "old" DBC to generate the code necessary to recreate the indexes.

Rick

 

[DSummZZZ]

If the .CDX files can be used, i.e. fields involved in the index tags are still used in the new tables, make sure the .CDX files have the same first name as the tables and do this:

USE thetable
SET INDEX TO thetable.CDX

This will "flip" the bit for you. In other words, it will reattach the .CDX file to the table.

Dave S.

 

[DaveL]

Thanks for the responses!

I don't want to recreate the indexes manually because there are too many indexes.

These are "free" tables and the CDX files have the same name as the DBF files.

I tried to use the code:

USE thetable
SET INDEX TO thetable.CDX

but I still don't see any indexes on the table?

Any other ideas?

 

[DSummZZZ]

Forgive me if I am oversimplifying, but did you do a

DISPLAY STATUS ?

If your files are in synch, DISPLAY STATUS will list the index tags, keys, etc., for your files. After that, you can execute

SET ORDER TO tagname

to utilize your controlling index.

Dave S.

 

[csr]

Well, it sounds to me like you are going to have a system with no way to recreate the indexes if they become corrupt.
Not a good idea. I would take the time to create routines which recreate the indexes and then just run that. Takes more time now, but less of a headache later when corruption occurs. Don
dond@csrinc.com

 

[DaveL]

csr,

I agree with your assessment of the situation. Can you give me an example of the code used to recreate the indexes?

Thanks!

 

[rgbean]

Have you tried running GENDBC.PRG against the "old" DBC to generate the code necessary to recreate the indexes? (It will also write the code to recreate all the tables, views and the DBC itself.)

If you don't have an "old" DBC, the general idea can be gotten by using any DBC (e.g. Tastrade).

Rick

 

[csr]

>Can you give me an example of the code used to recreate the indexes ?

Well, first you have to find out what each of the "tags" are. To do this, USE each of the files (1 at a time) and DISPLAY STATUS. You will then see the expressions for each of the TAGS.

Then it is simply a matter of writing code. And it goes something like this ...

use <filename) exclusive
index on <expression1> tag <tagname1>
index on <expression2> tag <tagname2>
etc ...
use

I must say this is pretty elementary stuff. I am wondering if you might be getting into something you are not ready for and are trying to start in the middle instead of learning things from the beginning.


Don
dond@csrinc.com

 

[DaveL]

I am not &quot;trying&quot; to start in the middle, I have been &quot;thrown&quot; in the middle. And you are right, I have no formal training in VFP. All I am working with is 17 years of programming experience, none of which is in VFP. The main problem for me has been learning the syntax, not conceptual. Largely because I have not been successful finding good resources for learning VFP, other than the forums.

Any recommendations for training or books on VFP would be appreciated.

But, I do appreciate the responses and help I have received on the forum.

Thanks!

 

[rgbean]

Hang in there Dave, I too had ~17 years of programming before I started in FoxPro, but since I've spent ~14 years with it since then, I'm beginning to think I know something <bg>.

See thread184-123948 for some books and web training. There are also a number of resources at the MS VFP website - White Papers, tutorials, sample code, and links to more.

http://msdn.microsoft.com/vfoxpro/

Rick

 

[csr]

Well, considering your situation, I would make one suggestion. If it is at all possible, I would not use the VFP database concept at all. I would use nothing but FREE tables. Using databases increases the complexities of VFP by a power of 10 (or more). I have been using VFP for years now, and still do not use databases. I do not need the headaches. Good Luck.
Don
dond@csrinc.com

 

[csr]

As I have been re-reading this thread, I am beginning to get a better picture of your plight. I have another suggestion. Here is what I would do ...

I would begin a new project somewhere and define each of the file structures that you need. Then I would open each of the new files and APPEND the data from the corresponding file in the old system. Then I would determine what TAGS (indexes) are needed for that file and write a routine which accomplishes that and run it (I discussed this earlier).

Do that for each file and when you are done you will have transferred all the data to the new project and the index routines will be completed. Then you can build your forms and away you go.

This may not completely address every situation but I hope it helps.

Don
dond@csrinc.com

 

[ChrisRChamberlain]

DaveL

Try Thread184-31035

Chris

 

[SMCmtg]

Don's comment above was:

&quot;I would not use the VFP database concept at all. I would use nothing but FREE tables. Using databases increases the complexities of VFP by a power of 10 (or more). I have been using VFP for years now, and still do not use databases. I do not need the headaches . . .&quot;

All my many tables are built in a &quot;database&quot; with simple and compound indexes etc. . .not being a &quot;programmer&quot; and learning vfp6 &quot;by guess/by golly&quot;! and reading the various inferences of the many threads, can somebody explain the pros and cons? (Don's comment makes me think I didn't read the books (so few!) or something!)THX Bill

 

[csr]

Whoa SMCmtg ..... You have opened a can of worms now ... Actually I guess I might have.

There are strong feelings on both sides of that issue. &quot;Young guns&quot; with a fiery taste for very complicated, powerful systems will swear by databases because of blah,blah,blah. And they are right ! There are many very convenient features of databases.

However, they do not come without a price. I will simply stand by my original statement about complication. It can become a nightmare and certainly requires a very much higher level of knowledge of the VFP software.

If you intend to be a guru of VFP programming, go for it. But if you just want to build simple applications without all the fuss, leave them alone. Don
dond@csrinc.com

 

[ramani]

Hi Dave
*********************************************************
** Author Subramanian.G
** Function to rebuild CDX index
** First deletes the index and then recreates them
** How to ... =BuildIndex(myDBF)
*********************************************************
** FUNCTION BuildIndex
PARAMETERS myDBF

LOCAL laIndex, cKey, cIndex

USE (myDBF)
DIMENSION laIndex(254,2)

*** Load the index name and key names in array
FOR nCount = 1 TO 254
IF !EMPTY(TAG(nCount)) && Checks for tags in the index
laIndex(nCount,1) = TAG(nCount) + ' ' && tag name
laIndex(nCount,2) = KEY(nCount) + ' ' && tag name
ELSE
EXIT && Exit the loop when no more tags are found
ENDIF
ENDFOR

*** Delete the tags
FOR nCount = 1 TO 254
IF !EMPTY(laIndex(nCount,1))
cIndex = ALLT(laIndex(nCount,1))
DELETE TAG &cIndex
ELSE
EXIT && Exit the loop when no more tags are found
ENDIF
ENDFOR

*** Rebuild Index
FOR nCount = 1 TO 254
IF !EMPTY(laIndex(nCount,1))
cIndex = ALLT(laIndex(nCount,1))
cKey = ALLT(laIndex(nCount,2))
INDEX ON &cKey TAG &cIndex
ELSE
EXIT && Exit the loop when no more tags are found
ENDIF
ENDFOR

USE
*********************************************************
** EOF
*********************************************************
** You can cut & paste and use the above function.
** Remember to backup & test this before/after execution.
** Accept it at your own risk.
** This is my contribution to public domain.
********************************************************
ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[SMCmtg]

THX Don for your comment and feedback. . .

&quot;If you intend to be a guru of VFP programming, go for it. But if you just want to build simple applications without all the fuss, leave them alone. &quot;

. . .actually I only know how to build them within a database. I haven't figured out how to do them as &quot;free&quot; tables. I guess what you don't know, won't hurt ya? and if it an't broke, don't fix it! right?