Solved Auto Index

[Gasman]

If I can help you in anyway with reducing the amount of data you need to work with, feel free to ask.
I still have VFP7 on this laptop. I would have to dig out my DOS and Windows FP, (if I still have them somewhere. )

I dare say I could extract just the data you need into new tables for you to work with?
If you want to send me a sample table to try, just let me know.

 

[Gasman]

Just a thought.?
Have you created the indices in Access, that you have in Foxpro?

 

[Space Cowboy]

Thank You Gasman that is very kind of you to offer.

What are indices? And where will I find them? I am going to PK them where I need them.

Indexing the new tables is my next job

 

[Gasman]

You would need to look at the cdx files. They hold any index on the data.
However, without some form of foxpro (bloody autocomplete on phone) , not sure how you are going to do that.

 

[Space Cowboy]

@Gasman

It appears straight forward, the most important field are all labeled *********_ID

I am going to re index every field that I intend to manipulate in case something has been lost in translation. I will do it manually for a bit to see if it improves things and then try to put in a VB method to index them all at once. I am going to need code to establish the relationships as well as I have to dismantle them before I can update the tables.

1 dismantle relationships
2 update
3 primary key and re index
4 re establish relationships

Any better way there then please advise

 

[Gasman]

TBH No idea.
Been a while since I played with Foxpro. :-(
Not even sure where the relationships would be stored.
They are defined in the Data Session window though. Not sure if they would remain permanent as in Access.

I can identify what fields have an index though, byt inspecting the table.

 

[Space Cowboy]

Thanks for trying Gasman.

Keys and indexes are remaining through linked tables so that is one job less.
will probably vanish tomorrow when I update tables. At least I have found the right place to put the code.

 

[Space Cowboy]

Thank you all for advice on indexes

Now running things at least 10x faster.

 

[ebs17]

In the current topic you should research with keywords like ... "foxpro data definition language".
The basic language of a database is SQL (Data Definition Language + Data Manipulation Language).
The first step in creating a database was something like "CREATE Database", long before there were access technologies such as DAO and ADODB or graphical interfaces.
These SQL commands still work today and can be chained into procedures, at the latest using a procedural language such as VBA.
You just have to bear in mind that different database systems can implement SQL standards differently and that there are therefore different SQL dialects. So you have to find the right SQL dialect for your database.

 

[Space Cowboy]

@Gasman
Thanks for that info, if I recall correctly adding more layers, interfaces etc just increases demand of processor and memory. Those old simple instructions will be very fast on modern PC, without all the baggage attached to every instruction. Oh for the purity of *.*
I will look into the VBA thing. I am going to keep my eye out for a foxpro db. there must be images knocking about somewhere.

 

[Gasman]

@Gasman
Thanks for that info, if I recall correctly adding more layers, interfaces etc just increases demand of processor and memory. Those old simple instructions will be very fast on modern PC, without all the baggage attached to every instruction. Oh for the purity of *.*
I will look into the VBA thing. I am going to keep my eye out for a foxpro db. there must be images knocking about somewhere.

There are, but none are cheap.

Visual Foxpro CD for sale | eBay

Find great deals on eBay for Visual Foxpro CD. Shop with confidence.

www.ebay.co.uk

 

[The_Doc_Man]

While doing some research on FoxPro, I found articles on one of the technologies that FP used long ago to give it a speed edge on PCs, something called "Rushmore" technology. It is based on compressed indexes. I also found articles that showed that when Microsoft bought Access from its original developer, they incorporated at least some of the RushMore tech into the DB engine. There is also talk about Visual FoxPro 9 being the last version and that MS will advise folks to head for .NET if they need to upgrade their VFP sites.

Sounds familiar in a way, because folks have been talking about the demise of Access for years. But VFP has apparently "officially" reached that dreaded "end-of-life" point. All I can say is, "Good luck going forward."

 

[Space Cowboy]

While doing some research on FoxPro, I found articles on one of the technologies that FP used long ago to give it a speed edge on PCs, something called "Rushmore" technology. It is based on compressed indexes. I also found articles that showed that when Microsoft bought Access from its original developer, they incorporated at least some of the RushMore tech into the DB engine. There is also talk about Visual FoxPro 9 being the last version and that MS will advise folks to head for .NET if they need to upgrade their VFP sites.

Sounds familiar in a way, because folks have been talking about the demise of Access for years. But VFP has apparently "officially" reached that dreaded "end-of-life" point. All I can say is, "Good luck going forward."

Hi Docman,
It will not be straightforward, my research has led me to consider that my windows is not the best at interpreting the necessary DOS commands. The backend is FP 9 and the earlier versions may not be compatible with either FP9 or Windows.

 

[Gasman]

I only have VFP7 but I can test for you?
I do not believe FP was as non backward compatible as Access is?

 

[Space Cowboy]

I only have VFP7 but I can test for you?
I do not believe FP was as non backward compatible as Access is?

what windows you on?

 

[Gasman]

Win 11. Not seen any issues yet.