Re: functional, user friendly databases

[Philip Hypes <phypes@lanl.gov>]

Thanks for the input.  Sounds like you have a good handle on what's going on;
I'll pass this along to the programming portion of the team.

As for the handwarmers, now you're just trying to get me in trouble...

At 01:35 PM 9/8/99 -0500, you wrote:
>
>
>Philip Hypes wrote:
>> 
>> Okay, I would love to hear from anyone out there in RADSAFE land who knows
>> of a good database program that can handle obnoxiously large databases.  A
>> research project I'm working on right now involves a system that is
>> continuously taking data, approximately once every two seconds.  We are
>> currently using Microsoft Access to handle files with as many as 1 million
>> data points, with 5-8 readings per entry.  The data files are in the dozens
>> of megabytes range, and Access is not handling them well.  It takes forever
>> to simply cut and paste a couple of days' worth of data into another
>> window.  Granted, this is a tall order, but I hope there is something out
>> there that can do better than Access.  Any suggestions?
>
>You think THAT's a big database?  I'll show you big... :-)  Now
>seriously, as a programmer, "big" means gigabytes of records.  I
>don't use Microsloth products but from what I've seen, I think
>Access should handle a database without too much trouble.  I think
>what you're running into is the Windoze clip board limitation.  The
>clip board, which was originally designed to hold a few lines of
>ASCII text, has been bastardized into a crude form of manually
>managed shared memory.  It does that rather poorly.  When you cut
>your data, somewhere (either in the application or windoze), the
>data has to be filtered into an interchange format.  Then when you
>paste to the other application, there has to be an on-the-fly
>conversion to the specific data format of the receiving program, all
>the while, keeping the window nice and pretty.
>
>As a test, and perhaps as an alternative, you might try exporting
>the selected data to an interchange format, say CSV, and then
>importing it into the new application.  If this runs much faster,
>then you know where the bottleneck is.  You could either develop a
>macro to automate this or you could move up to a more advanced
>database manager.  Any of the "real" programmable database
>environments (FoxPro, Informix, etc) should handle this just fine. 
>Of course, the REAL solution is to put this application on a Linux
>box with a real operating system :-)
>
>> In case curiosity is driving you wild, the system in question measures
>> plutonium mass by measuring the heat output from the source (calorimetry).
>> It's currently the most most accurate and precise nondestructive assay
>> system for plutonium.
>
>Hey, I'll trade you some database programming for some Pu. Enough to
>make a couple of nice hand warmers for this winter's hunting season
>:-)
>
>John
>
>-- 
>John De Armond
>johngdSPAMNOT@bellsouth.net
>RDS Inc.
>Cleveland, TN
>************************************************************************
>The RADSAFE Frequently Asked Questions list, archives and subscription
>information can be accessed at http://www.ehs.uiuc.edu/~rad/radsafe.html
> 
___________________________________________________________
Philip Hypes
Los Alamos National Laboratory
Safeguards Science and Technology Group (NIS 5)
(505) 667-1556  phypes@lanl.gov

Opinions expressed are purely my own unless otherwise noted

************************************************************************
The RADSAFE Frequently Asked Questions list, archives and subscription
information can be accessed at http://www.ehs.uiuc.edu/~rad/radsafe.html