× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Externalize DB/IO
  • From: "DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
  • Date: Wed, 11 Apr 2001 08:13:12 -0500

What about using tag based structures (like XML) to pass data. All data
would then be passed in clear text and could be easily parsed to extract the
data you need. 

Eric DeLong

-----Original Message-----
From: NSmith@lincare.com [mailto:NSmith@lincare.com]
Sent: Tuesday, April 10, 2001 4:12 PM
To: MIDRANGE-L@midrange.com
Subject: RE: Externalize DB/IO


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
+---

+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.