Thanks, Larry.  I will attempt a trial transition you suggested some
time this week.  I assume from your description that whenever I change
the file (if it is stored outside of the database) the change will be
automatic in RBASE as long as the file path does not change.  Is that
correct? If so, that eliminates one more step.  When files are outside
the database like that, how is the speed affected in reports, especially
if I am printing a lot of drawings?

 

jim

 

________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of Lawrence
Lustig
Sent: Wednesday, April 29, 2009 10:55 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: Instruction files in table

 

<< 

I now presently have a table that contains my assembly drawings (BMP
files).  In regards to your suggestion about the DOC files, should I
also store the path to those BMP files rather than having them stored in
my table?  Or are BMP files handled differently?

>> 

 

Anytime you suck files into the database as VARBIT columns, the RB4 or
RX4 file is going to grow by at least the size of the disk file you're
storing.  If those files are at all large, your #4 file will begin to
grow quickly.

 

For a small and predicatable number of smallish images, I'll store them
in the database.  For a growing list of files, I just keep references to
the disk file.  In fact, I store the "root" of my document storage
system in a system configuration, and only the relative path and
filename to the file.

 

So, one client has a table of three or four logos that have to appear on
various documents.  Each one is about 80K.  I store those in the
database.  They also produce a large number of PDF files (perhaps 50 a
day), each between 50K and 2M.  Those, I store on disk in a bunch of
folders under a location called \\TheirSvr\RBSystem\Documents\.  That
location is stored in my SYSTEMVALUES table so, if it changes, I can
change the table and not the code.  Then, my file links are in the form
Reports\Shpping\Ship_20090428.PDF, Invoices\Inv_22101.PDF, and so on.

--

Larry

 

Reply via email to