Ugh. "modern" windows medical apps use Microsoft access runtime (Jet) as the db backend. It is total crap. More worthless than Access is.<br><br>OK. You're not totally hosed as you have mirrored drives. However, there's no good way to know about how the system will respond to a "drive out" failure without testing. That will be scary. PLan a weekend with backups and extra drives pre-mirrored.<br>
<br>Specifically, if a drive simply fails (think lost power failure), it is a safe assumption that the remaining drive has good data. However, if a sector on one drive become corrupted and a sync occurs before the drive can relocate that sector, which sector trumps? Failed sector will not flag the drive as failed to the RAID controller but now there are two different data sectors. Since the system is running a rather fragile filesystem (I can't bring myself to call the jet process a database with a straight face), that crappy sector actually has a fairly high likelihood of crapping out the process unless the app designers have implemented an extensive automatic recovery process. Of the medical apps I've seen over the past 10 years, there seems to be more code devoted to recovery than storage for this very reason. Multiple backup indexes, duplicate database containers, etc. are quite common in systems using Microsoft Jet. They use it because it's a no cost tool to implement and yet it has no upward migration route that is less than a total scrap and rewrite to migrate to larger backed ends like MSSQL server.<br>
<br>stupid, simple flat files would be better and more reliable than using Jet. Oh. Wait! That's basically what Jet is just without any way to access the data without Jet since the file format is proprietary not from Jet but from the mediacl app vendor! AARRGGHH!!!!!<br>
<br>In your case, you _could_ test that a failed drive will not cause instant system death. Also be sure that the drivers for the mobo RAID stuff are installed and that it is all set to send a "HELP!" if a drive event occurs. <br>
<br>There are _some_ Open Source medical practice management tools around but they are either for hospitals (The one sponsored by the VA is GPL v.2 and paid for with federal $ and very, very good) or they are not quite ready yet to be the sole tool. <br>
<br>That said, the two I've been watching, and I think they are ready for use now are medical <a href="http://medical.sourceforge.net/">http://medical.sourceforge.net/</a> and openEMR <a href="http://www.oemr.org/">http://www.oemr.org/</a><br>
<br>Migration and training are nightmares, btw. The medical world loves technology but loathes changing it. Computers are still rather scary things compared to a defibrillator or a blood pressure monitor. What I have seen that actually does work is to have the systems used for the medical app do NOTHING else but that single tool. Put browsers and email somewhere else so the app system is seen not as a computer but as a single purpose tool for accessing and recording medical history and practice data.<br>
<br><div class="gmail_quote">On Tue, Apr 13, 2010 at 10:21 AM, William Fragakis <span dir="ltr"><<a href="mailto:william@fragakis.com">william@fragakis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Opinions requested from those wiser/smarter than me (which includes all<br>
of you, your pets and probably your houseplants):<br>
<br>
My wife's medical practice management software writes to a closed source<br>
database*. Prior to Jan, the version of the database we used allowed for<br>
"hot" backups - you could copy (we used rsync) the files to another<br>
server while the database was in use. Thus, we could make hourly copies<br>
as well as the usual nightly copy which was also sent off site. The<br>
hourly copies were written to a duplicate machine so if the primary data<br>
server failed in any catastrophic way, we'd have both the data and a<br>
machine configured to serve it available quickly. Losing an hour's worth<br>
of work seemed to be the level of risk we felt we could assume. We don't<br>
feel comfortable losing a day's worth of work. Of course, the database<br>
and the duplicate both use RAID 1, the primary server using Windows and<br>
hardware (motherboard) RAID and the backup, Linux software RAID.<br>
<br>
While the risk of losing both disks of a RAID are statistically low, I'm<br>
freaky about both data preservation and availability.<br>
<br>
Since Jan., an update in the database version prevents us from making<br>
live copies (we either have to kick off all the users or ignore file<br>
locking, both not what you want for obvious reasons). We can still make<br>
nightly backups but we are "naked" (at least it feels that way) for the<br>
next 24 hours.<br>
<br>
Ideally, we'd just migrate to an open source solution but, invariably,<br>
it's not that easy (or at least quick).<br>
<br>
In the meantime, am I being overly paranoid or should I be concerned? Of<br>
course, the vendor is telling me that I'm worrying over something that<br>
has a low probability and at this point has no plans to add a utility to<br>
the management program to allow live copies - which they could do but<br>
won't. I can't do it directly because they won't give us the level of<br>
access to the database we need to do it ourselves. Thoughts?<br>
<br>
TIA,<br>
William<br>
<br>
*Advantage Database ver. 8.1<br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br>Actively in pursuit of Life, Liberty and Happiness <br><br>