Re: Working with fixed format text db's

On Jun 9, 7:55 am, Jeremy C B Nicoll <jer...@xxxxxxxxxxxxxxxx> wrote:
Neil Cerutti <horp...@xxxxxxxxx> wrote:
On 2007-06-08, Jeremy C B Nicoll <jer...@xxxxxxxxxxxxxxxx> wrote:
Neil Cerutti <horp...@xxxxxxxxx> wrote:
Luckily, the output format has not changed yet, so issues with
maintaining the above haven't arisen.

The problem surely is that when you want to change the format
you have to do so in all files (and what about the backups
then?) and all programs simultaneously.

I don't have control of the format, unfortunately. It's an import
file format for a commercial database application.

You're saying your program merely has to read data files created by that
database app? It's not that you have a whole suite of programs that create
and read these files, nor that you have years worth of old files that would
need their format converted if the programs were changed?

It is not actually *hard* to do this with ad-hoc code, but then
the program is indecipherable without a hardcopy of the spec in
hand. And also, as you say, if the spec ever does change, the
hand-written batch of ljust, rjust and slice will be somewhat of
a pain to reconfigure.

You could presumably define a list (of some sort, might be the wrong
terminology) that defines the 'name', type, length, justification and
padding of each field, and then make the explicit code you showed loop
through that list and do what's needed field by field.

There's a risk that abstracting the definitions will make the code less
clear to anyone else; at least it's clear what the current stuff does.

But biggest weakness, to me, is that the specification is not in
the code, or read and used by the code, and I think it should be.

It'd be better if you could read the data layout spec from some file
produced by the database system. No chance perhaps of having the dat files
include some sort of dummy first record that contains the necessary info in
a form that you could interpret?

The OP is *WRITING* not reading.




.

Relevant Pages

  • Re: Working with fixed format text dbs
    ... I don't have control of the format, ... file format for a commercial database application. ... And also, as you say, if the spec ever does change, the ... You could presumably define a list (of some sort, ...
    (comp.lang.python)
  • Re: Btrieve legacy migration
    ... The first question is to figur eout your file format and database ... and get the white paper on "Finding Your Database Engine Version". ... do a STAT of one of your data files to determine ... or a description of the file format. ...
    (comp.databases.btrieve)
  • Re: DoCmd.TransferText error with Schema.ini import specification
    ... spec. ... The database engine doesn't care. ... it for subsequent imports with the TransferText method. ... Function fncImportTextFile(strImportTbl As String, blnRow1FldNames As ...
    (microsoft.public.access.externaldata)
  • Re: Two questions about moving data between a SQL DB and XML
    ... better method of exporting data to a file format for later reimport be? ... Is there a better option than XML? ... dozen tables from one database and importing them into another database ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Database Stuff
    ... You don't have to have Access installed to use it's file format. ... Set ogAccess = Nothing ... End Function ' OpenDataBase ... of separate machines such that each person is accessing the same database ...
    (microsoft.public.vb.general.discussion)