Not a Database file.

[newtofoxpro]

I am fpw26 user and I have experienced "Not a Database file" error many times. For some reason I am going to migrate fpw application to vfp8. Is anybody experience this error in vfp8 ?

Example.. Planning in fpw26...

If I want to use large customer database. Records 500,000 approx. I would prefer to split those records in multiple DBF. Like Countrywise. Because it becomes easy to optimize query for me.

1) I would create COUNTRY.DBF ( Cntry_ID, Cntry_Name )
2) I would create "CUST"+Cntry_ID+".DBF"

this way I can create my tables in fpw26. In this tables If something goes wrong with any table 'Not a Database file' I can repair that table with fpw code.

But while learning VFP8 I found, I can create database and its tables. If I am right, on Hard-disk i can find single database file.

With VFP8 I can make CUSTDATA as database and COUNTRY.DBF & "CUST"+Cntry_ID+".DBF" tables as part of database. Am I right ?

Now, If something goes wrong with a table, Is that affect to all tables or database ? Or still I can use database and its other tables.

 

[Timalaugh]

VFP 3 through 9 are totaly excellent.
Once you learn VFP 8 you will never want to go back to 2.6

I can only say that you should take some time to learn VFP 8
It is very intuitive and fun to use.

then you will have no trouble moving your 2.6 data over.

enjoy
Timalaugh

 

[Mike Lewis]

With VFP8 I can make CUSTDATA as database and COUNTRY.DBF & "CUST"+Cntry_ID+".DBF" tables as part of database. Am I right ?

Yes, that's competely correct. (Whether splitting tables in the way you described is the best approach is another question, but you didn't ask about that.)

If something goes wrong with a table, Is that affect to all tables or database ? Or still I can use database and its other tables.

It depends what goes wrong. If you lose the index or memo file, that won't affect the database in any way, and you'll still be able to open other tables. But if the DBF's header gets corrupted, you might get an error message when you open the database - although even that probably won't affect other tables.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

From a application data architecture perspective I'd recommend that you NOT create tables like: "CUST"+Cntry_ID+".DBF"

You would be better to create one or more CUSTOMERS (or whatever) table containing a unique CNTRY_ID field for each record.

Then if you need other associated tables, create them using the CNTRY_ID field as a 'common' field between all of the tables. In that way the various tables can be RELATED for use within the application.

Also don't forget to look into Normalization of your individual data tables.

You might want to have a look at the free on-line VFP tutorial videos at:

http://www.garfieldhudson.com/FreeVideos.aspx

Some of it will be a repeat of what you already know from FPW, but some will be new for VFP.

Lastly I'd recommend going to VFP9 instead of VFP8. VFP9 is the latest version and has a good number of enhancements over VFP9 - although either is WAY BETTER than FPW.

Good Luck,
JRB-Bldr

 

[newtofoxpro]

But while learning VFP8 I found, I can create database and its tables. If I am right, on Hard-disk i can find single database file. "

No, it's not like this. I run following code.

CREATE DATABASE people
CREATE TABLE people1 (FirstName C(20), LastName C(20))
INDEX ON FirstName TAG one
CREATE TABLE people2 (FirstName C(20), LastName C(20))
INDEX ON FirstName TAG one
CREATE TABLE people3 (FirstName C(20), LastName C(20))
INDEX ON FirstName TAG one

And I run CMD and type dos command DIR PEOPLE*.* It appear as following...

11/08/2011 07:38 PM 3,358 people.DBC
11/08/2011 07:38 PM 960 people.DCT
11/08/2011 07:38 PM 4,608 people.DCX
11/08/2011 07:38 PM 3,072 people1.CDX
11/08/2011 07:38 PM 360 people1.DBF
11/08/2011 07:38 PM 3,072 people2.CDX
11/08/2011 07:38 PM 360 people2.DBF
11/08/2011 07:38 PM 3,072 people3.CDX
11/08/2011 07:38 PM 360 people3.DBF

i.e. tables is not content of database it has Separate existence on the hard-disk.

 

[Mike Lewis]

Yes, that's right. Tables exist is as separate physical DBF files. They are part of the database, but only at a conceptual level. It's not like in Access, where all the tables (and indexes and everything else) are bundled into one physical fle.

But there are sill many advantages in using a database (and a few disadvantages). There's an article on my website (DBCs or free tables? The pros and cons) that discusses some of them.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy