[AccessD] Re-Invent The Wheel??

Hi John

Well, that's the difference. Specifications for these formats go from 30 to 70 pages. As all sorts of ERP apps use these specs it causes a lot of trouble if they are changed. 
If you have control of both ends, life is much easier. But in that case you would today probably choose XML for the format as that eliminates many of the problems here.

"Anything" in a fixed width field would for me be spaces. You'll notice my heavy use of Space(n) cause even in monospaced coding it's hard to see if you have 18 or 20 spaces in some code string - it takes forever to debug such things.

/gustav

>>> jwcolby at ColbyConsulting.com 18-10-2005 15:38:32 >>>
Gustav,

I certainly appreciate the "hard code" approach, I have doe that myself.
OTOH, I have had a handful now that were fixed formats but needed
"adjustments" to get it just right.  For example:

I am working on an export (and later an import) to the US government for
what is called PlanD, having something to do with medicare re-imbursements
to the city government.  The upload specification is VERY loosely defined,
basically they say "fixed width (with field widths specified), comma
delimited, with no header (field name) line, then they specify the format
inside of date fields to be YYYYMMDD.  And THEN they say "if there is no
data then you don't need anything in that field, but the commas must exist.
So much for FIXED WIDTH!!!  The issue here is that there is no upload test
site.  How this is going to work I don't know, but we will submit a batch to
them "hoping" that it is in the format they want, and they will either
accept it, or they will respond "change this thing over here".  Seems pretty
stupid to me, but that is what I am dealing with.

Another example:

The first system I built was for an insurance company.  This insurance
company is in the middle of changing their software to a package they
purchased.  It is mainframe stuff, and so they dumped an export spec into a
spreadsheet of a series of records consisting of their field name, start /
end position, data type (string, numeric, date etc) and format CODES such as
date, fixed, str etc.  I did the "hard code" routine, then they promptly
came back with "yea but this field has to be fixed with 4 decimal places,
this one has to have two decimal places, this date has to have ddmmyy, this
one has to ...

This is STUPID.  So I built a table from the spec they sent, added my own
fields to add a format string, and a code for left / right align etc.  This
really does work.  They are apparently adjusting something out in their
system because they have come back with "ok, add these fields IN THE MIDDLE
of the string... At which point I added a "field position" field (numbering
the field's position in the BigString).  Voila, I just change the field
position and shove the fields around as I need.

Of course if you are dealing with a format cast in cement, where they
actually know what they want, and provide a CLEAR specification, then just
"hard coding" the solution works fine.  OTOH, if you can design a table
driven system that works, then you can just open the table and modify the
necessary parameter as the client waffles.

This does work, I am using it with my waffling insurance company.  I haven't
changed my code at all since I moved to the table driven design.

After doing this a few times, it becomes obvious that there are field
objects, there is a data set object, and there is an export object.  Design
a system to fit that and it will probably work just fine for many, and
perhaps most such exports.

John W. Colby
www.ColbyConsulting.com