Hi everyone,

Before I say anything I want to say if you can help me with this problem it would be greatly appreciated as I really am unfamiliar with databases. However, here it is:

I have several .dbf files, currently 6 of them. I have one main file called products, which contains many different column headings. However three of them are: GRP, CAT, and SUB. Under those headings there are a lot of different variables that represent an actual phrase or group of words in another .dbf file. For example in the other .dbf file there are GRP: b3 CAT: j1 and Sub: a1 = no power supply and in the products file there is simply a jumbled up list of GRP: b4 CAT: J2 Sub: a5 but not = phrase or description. How do i combine this file into the products file so that these three columns will translate those three columns into a Descr or description column in the product file itself?

Essentially, I am trying to compile one sub file with another main file to equal phrases etc.

If that got confusing I have also included photo images of what I said above.

If you have any questions please don't hesitate to ask and any help is greatly appreciated!

I am also using CDBF DBF editor/viewer as my program for these database files. Also, if that is not a good free program to use what would you suggest as a free alternative? I have a database I will upload them to I just need to contrast one master file.

Thank You!

Jamie Greene

Generally when you have multiple DBF files they can be one of 2 things, depending on where the files came from.

1. If all 6 DBF files came from different sources, then they COULD be all the same, but with data from the differing sources.

2. If all 6 DBF files came from the same source, then it is likely (the MOST LIKELY situation) that the files are in some way related to one another. One file being the 'parent' (or 'master') file and the other files being 'child' files each containing some data related by some 'linking field' or 'field expression' to the 'parent' table.

The DBF 'viewer' will allow you to 'look at' the file content, but I doubt that it will support your manipulating the content.

I cannot say for certain which language was used to create the DBF files. That file extension was previously used by dBase, Clipper, Foxpro, and there may be a few other languages that I don't know about. And certain languages today can still create DBF files.

Additionally there are version-specific bits in the file headers which generally define the language version which created the file and many versions are not 'upwards' compatible to the language - meaning if the file were to have been created in Foxpro 2.6 for Windows and you tried to open it with Foxpro 2.5 for DOS (an older version), you would not be able to do so.

I might recommend that you try to find a copy of Foxpro 2.6 for Windows and see if you can work with the data files with it.
You might find a copy on:
1. eBay
2. Microsoft FoxPro/FoxBase version information
3. DBMS - page 2 | VETUSWARE.COM - the biggest free abandonware collection in the universe

I have never gotten software from those sources so be cautious of anything you get. If all works well, then come back and we can help you with using the language to accomplish what you want to do.

Another alternative might be if you can open the DBF files in Excel (2003 or earlier). If you can do that you will have the data in a format that you can save into another format and then manipulate as you need.

Good Luck

a free alternative would be open office, although how 'good' a databse product it is I dunno. I looked at it a while back and it seemed very limited compared to the likes of Access. howeverr its limitations may not be a problem for what you want to do. Bear inmind open office intends to use the pareto approach, its not intending to compete with MS Office products but tries to do the 80% of things people use MS office type products for with about 20% of the software effort and not support the more esoteric things you can do in MS Office. so if your requirements are NOT for an all singing all dancing tightly integrated application then it may well be worth looking at.

FWIW the dbf format dates back to Ashton Tate's dBase II, and has since been released as an open format as xBase. in its day it was a good product, but the application tools are dated these days and hevn't neccesarily kept up with developments elsewhere

Lets handle your comments separately.....

"three of them are: GRP, CAT, and SUB. Under those headings there are a lot of different variables that represent an actual phrase or group of words in another .dbf file."

The description you provide of the multiple DBF files suggests that it is like I describe in #2 above.
One table is the "parent" table containing the 'master' information and the other tables are some how related to the first.
In the specific situation you describe, the 2nd data table (DBF file) contains the options available for each GRP, CAT, or SUB. Typically this would be used in an application to provide the users with choice options that could be selected and then applied to the associated field in the 'master' information record.

I'd guess that the other data tables (DBF files) work in a similar manner.

"How do i combine this file into the products file so that these three columns will translate those three columns into a Descr or description column in the product file itself?"

What do you mean????

If you want to extract the information into some other format for use elsewhere, you can do as I suggest above and then manipulate the data as needed.

If you want to create a new APPLICATION to use the data from those data tables (DBF files), then you have set yourself a challenge. You would first have to LEARN a database language (such as Access, Visual Foxpro, VB .Net, C#, etc.) and then utilize the data you acquired from the data tables (DBF files) that you have.

If you were to choose to use Visual Foxpro - it could use the existing data tables (DBF files), but first you would need to LEARN the language and then decide how you wanted the APPLICATION you developed to work while using the data tables.

Good Luck

Hi everyone and thank you for your help. Essentially what I need to do is I need to create the "child" files or the files related to the master into one big "master" or "parent" file. I need this as I am ultimately trying to make one big master file to put into my MYSQL database so that my coding can read from the table. I have an online retail store, and this code I have is going to read off of the table so that it can display the information as "product information". That is why I need all of these related or "child" files into one big "parent/master" file so that my coding can read off of the master file and display it all as individual product information.

With that being said, what program do I need to do this, or can I put these files in my MYSQL database so that it simply reads all of them and puts them into order so that it reads all the information as the product information. If so how do I do this? If you don't want to explain any links to a tutorial is greatly appreciated as I understand explaining can take sometime.Also, these six files have columns relating to the master file to insert special information like product description, categories etc, which is found in the attached files. I also got the 6 database files from the same source if this helps.

Thanks Again I really appreciate this!

If you do a Google search for either:
MySql DBF
or
DBF to MySql
you will find a number of options to use to "convert" the DBF data tables into MySql formatted data tables.

By itself, this 'conversion' will not convert the various 'child' data tables into one big MySql data table, but once you have the data from the various files into a format that you are familiar with, you should be able to do whatever you want.

BUT it is not good data architecture design to put all of the information from all of those files ('master' AND 'child' tables) into one big data table. Plus it may not make logical sense to do so.

If you are already familiar with it, I apologize for the upcoming suggestion...
If you are not familiar with data normalization you might want to study up on it.
A Google search for
data normalization
will turn up a number of references.

You might want to re-think that over-all approach to how you would like your data organized.

Lastly....
"can I put these files in my MYSQL database so that it simply reads all of them and puts them into order so that it reads all the information as the product information"

How much programming do you know?
Again I will apologize if you know this already, but just putting the data into data tables within a MySql database will not automatically allow the data to just pop-up into an existing application.

If you already have a MySql data table which your application uses for this purpose and you would be merely adding new records to the existing table - fine.
But if you do not already have your application using a data table for this purpose, you will need to use programming to modify the application to do so.

Good Luck

jrbbldr,

I have existing coding, and I am simply modifying the tables, or data. I also know how to turn the .dbf files into the MYSQL tables, however thank you for your suggestions.

What I really need to do is combine the "child" files into one big master file, or if this is a poor design then how do I make the "child" files information pop up with the corresponding product information. Is there a coding where I can match up two columns to another corresponding two columns so that that particular information can match up with the other information?

For example:

I have one dbf file that contains the following columns

First DBF File ( basically a key )

GRP CAT SUB Description
a1 b2 c6 Laptops
a2 b3 c7 Desktops
a3 b4 c8 Servers

Second DBF File ( jumbled up information )

GRP CAT SUB

a1 b1 c5
a4 b3 c6
a7 b8 c9

End result:

The second dbf file would turn into the keys and would add the proper information.

The first file I guess is acting like a "key" or guide and the second is a bunch of jumbled up information.

How do I combine these files so that the key will match up with the second .dbf which is the "master" file that has all the jumbled up information, and replace the master files information with the keys?

The information would then read off a table in a database and would make it look like ordered information combing all of the "keys" information into the master tables information with each corresponding row.

I think there is a simple excel code, but I am not sure how to do it, and I am not sure if that is what I need.

Do you see what I am trying to do?

Again, I really appreciate you taking your time to do this.

I can give you some suggestions on how to combine the data from the 2 data tables (see below)

But, from the example data you show, I cannot see why you would want to do that.

Ending up with something like the following in a single data table:
GRP CAT SUB
a1 b2 c6 Laptops
a2 b3 c7 Desktops
a3 b4 c8 Servers
a1 b1 c5 ______
a4 b3 c6 ______
a7 b8 c9 ______
doesn't look to me like it would be of much benefit to you.

"How do I combine these files so that the key will match up with the second .dbf which is the "master" file that has all the jumbled up information, and replace the master files information with the keys?"

1. You could open each DBF data table into Excel 2003 or earlier and then combine all the various worksheets with Cut & Paste into a single Excel worksheet.
2. Then with your cursor Select all populated Rows & Columns (do not select those empty Rows and/or Columns beyond what you need).
3. Then do a Save As... using the DBF4 format

So now you would have the data from all the desired DBF files into one single DBF file.
Convert it to a MySQL table in the manner you choose.

"The information would then read off a table in a database and would make it look like ordered information combing all of the "keys" information into the master tables information with each corresponding row."

Again I am not certain of your programming background so again I will sincerely apologize in advance if what I am going to say is an insult to you. It most certainly is not meant to be that. But some individuals on this forum really don't have a clue about the difference between DATABASE's, and APPLICATION's.

So, at the risk of unwantingly insulting you, here goes....

An APPLICATION is what a user interfaces with to get data out of and back into the data tables within a DATABASE - regardless of the database type. An APPLICATION is created with Programming in some language.

Your Retail Application is just such. And it is written in some language (such as - VB, VB.Net, C++, Access, Foxpro, etc.). That Application USES the MySQL database to contain its data tables which in turn contain the various pieces of data that are needed to run your business. MySQL is not the Application and it is not a language that can write an Application.

Just putting the DBF file data into a MySQL data table will not, by itself, cause the new data to suddenly appear in your user's application.

You have not indicated how you intend to have this new data "appear" as "information pop up with the corresponding product information."

Unless your application already uses an existing MySQL data table to do this and you will be adding this new data to that existing data table, you will not 'magically' begin working like you suggest just because you put the DBF data into some new MySQL data table.

"combine these files so that the key will match up with the second .dbf which is the "master" file"

If you cannot do this by manipulating the 'raw' data in the data tables, then this will have be be accomplished with Programming within your Application.

Good Luck

I thought of another analogy for the APPLICATION - DATABASE differentiation issue.
An automobile.

A user wants to go from point A to point B and wants to use a Car.
A user wants to perform some tasks on their computer - they use an APPLICATION.

But the Car needs things to work. It needs fuel, lubricant, cooling fluid, etc. to run.
An APPLICATION also needs things to work - data. That data is contained in data tables which may or may not be contained in a DATABASE.

For the car analogy, the "Data Tables" would be the fuel tank, the oil sump, the radiator, etc. and they are contained within (or near) the car engine - the DATABASE.

The user can put more fuel, lubricant, etc into the car and get more miles traveled out.
The same goes for an APPLICATION. As more information goes in, more can be done.

Now if the user just decided that they want the car to also run on Electricity or maybe Diesel fuel, they would be out of luck unless the car and its parts (the engine) was already DESIGNED to do so. The same applies for an APPLICATION.

In the same way that putting an electrical cord under the engine bonnet will not enable a car to make use of it, just changing what might be available (the data) for the APPLICATION does not, all by itself, enable that data to become available for use by the users.

I can add more of something that is already 'known' (more of the SAME fuel, more data to EXISTING data tables) to these and that new ingredients will be used just fine.
But adding something totally different/alien to them will not work.

An APPLICATION needs to 'know' how to use new and DIFFERENT data.
Either it was originally designed with that flexibility already in it or not.
If not, then new software development needs to be done to the APPLICATION to add the capability of using this new type of data.

Good Luck