Exporting a Collision Supplement using the CIECA EMS Standard

You can use DAO to access it, but if the dBase files are making heavy use of indexes the you will have trouble.  We use dBase for our order entry system here, and I have spent the last year working on VB code for working with dBase.  It seems that I can anything I want with the database.  The only problem is that the software we use freaks out afterwards.  Some other software that can read dBase seems to think my dBase files created with VB are just fine.
Personally I would go with a dBase OCX/ActiveX control/dll for dBase access.  It really isnt worth all of the headaches involved trying to do it yourself in VB.

I suppose that if you have all of the file header info for the EMS version of dBase files then you shouldnt have any problems.  You can just use ADO to do any standard database work and write a routine to create a compliant file to put the data in.

The software I'm working on will only export the files in dBase format, so I'm not concerned with reading them.

So are you able to create dBase files within VB code, specifying field headers and then adding in records?  I may have to create the files in Access first, then save them as dBase IV format, which is OK (I've got the field specs for the files).

The program uses Access databases (mdb extension, I think) to operate.  I've got to convert those db's to dBase IV as an export to be imported into collision systems.  That's the main goal I'm trying to find more info on.  Collision systems can expect up to 15 files for a particular import, so I'm also after more detail from someone who has actually worked on this type of stuff.

Thanks - MT

ok I was confused I thought that the CIECA EMS Standard  extended the standard dBase IV format.  I browsed through the CIECA EMS Standard 2.5 since 3 was not available on the site.
http://www.cieca.com/CIECA%20Stds%20and%20Guidelines.htm

If you know how to use ADO then it will be a breeze,  you can use this connection string to open the database.
oConn.Open "Driver={Microsoft dBASE Driver (*.dbf)}; DriverID=277; Dbq=c:\somepath"
The basic idea of dBase files is this.
A directory represents a database, and all of the dbf files in that directory represent tables in the database, this is why the connection string above only references the path and not a file name.

You would then specify the file names when executing SQL Queries like this:
"SELECT * FROM COLLISIONS#DBF WHERE ESTIMATE > 1000.00"

the period in the file name should be replaced with the # sign.

If you want more info just let me know.

So if I'm following you correctly, what they refer to as a "package" is actually a directory?

Is the Envelope (*.ENV) file the first thing dBase looks for so that it knows what the directory contains?

no, as far as I understand it, any directory is a database as far as dBase is concerned.  If no tables exist then it is simply a empty database.

I have not heard of a ENV file, is this something that is specific to the system you use?

.ENV file is part of the EMS standard.

Are you able to create dBase files with VB code, or do you have to create the dBase tables first, then modify them with VB code?

I'm familiar with ADO, so any code samples for working with dBase (other than select queries)?

Thanks.

OK.  Great.  I'll try this out and see if I can't make this work.

I'm not sure if it's going to fly or not though, because I have to save the files using the differnt file extensions specified by the EMS standard (.ENV, etc.).

Thanks for the help.  Although you didn't give me specific information on the EMS Standards or collision app related code, I appreciate all your efforts here and the fact that you actually checked out the 2.5 Standard on the CIECA website before commenting.  Much appreciated.

MT

not a prob, let me know if things worked out it...