RE: Externalize DB/IO

[NSmith@xxxxxxxxxxx]

The trick is to not tie it to a datastucture defined by a DB file.  Either
make it more specific, like GetCustName(Custno) or pass a datastructure that
is not tied to the file.  It can still contain most of the oft-used fields,
but it would allow you to change the file(s) without touching the programs
that use the procedures.  Of course, when you change the fields in the
datastructure, you would then have to change the calling programs.  This
separation also would allow you to do things like combining the data from
several files into one datastructure that your procedures use.  i.e. the
datastructure could be in essence a flat-file format saving the program from
having to bring in all the related relational tables.  It can really save
tremendous amounts of complexity in the application program.  

When you need customer data, what's wrong with getting, in one big
structure, everything you have stored about that customer, without regard to
all the different files the data is actually stored in?  Let a middle-ware
procedure assemble it all for you. Then you change your procedure from
GetCustMastRecord to GetCustomerData. Then, once you've written one, it's
very easy to derive others, like GetActiveCustData which just calls
GetCustData and loads only the active records.  About as close as we can get
to Object-like programming.  

Programs need data, not files.

> -----Original Message-----
> From: Gwecnal@aol.com [SMTP:Gwecnal@aol.com]
> Sent: Tuesday, April 10, 2001 12:51 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: Externalize DB/IO
> 
> If you externalize all db/io and provide a bunch of funcitions like
> GetCustMastRecord
> UpdateCustMastRecord
> etc
> and each of them passes a key and a data structure to hold the
> data, don't you still have to hunt down and recompile all the
> programs when the data structure changes?  How have you
> helped yourself? I'm not fussing, I really want to know.
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message. 
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer. 
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---