|
|
|
| Authored by: Anonymous on Friday, September 07 2012 @ 09:46 AM EDT |
| Which is why WINE is so important. [ Reply to This | Parent | # ]
|
| |
| Authored by: newbury on Friday, September 07 2012 @ 11:18 AM EDT |
But even those MS-based vertical apps store their data in some known format. OK
there may be some very old stuff out there which is *actually* based on a
singular fully proprietary format but those can be counted on one hand. Anything
major will use a pre-written database back end. It may not be designed to export
information, but any real database has admin tools which will allow direct
access to the db. It will not be 'impossible' to export the data. It may just
need external access to the db.
Most proprietary MS software does not discuss how the backend works. The backend
just gets pulled in and installed as part of the software install. FOSS software
lists the backend as a requirement. So the user knows which backend is being
used.
Good FOSS software runs tests at installation to determine whether the
requirements are met. The MS stuff I have seen (admittedly a very small set of
examples) just installs what it needs. For FOSS examples see nolapro, zencart or
opencart. Ms likes to leave the user entirely in the dark about what is actually
being done with the data. The proprietary software company likes this. Any
spelunking of the data means consulting revenue.
I have a very old accounting program (1987) which now runs in a DOS window in a
WinXP VM or under DOSEMU in fedora. The backend is not particularly 'visible'
but it is actually a Btrieve structure. (Anyone else even *remember* Btrieve?)
Not easy to deal with, but if I had to, it would not be impossible.
And in the case of the Vet, there is no reason why he cannot set up a new system
and run them side by side during the teething period until he is satisfied with
the new system. If it all goes pear-shaped for his purposes, he's only out the
hardware cost and any technical help.
I have to admit that we sometimes forget how spoiled we really are. If I want to
backup, or to move the data from my databases, mysqldump is right HERE to do the
job. I'll undoubtedly have to check the man page but backup or export is NOW.
Import is not much more difficult.
Thanks to the devs! We forget to say that!
[ Reply to This | Parent | # ]
|
| |
| Authored by: Wol on Friday, September 07 2012 @ 12:59 PM EDT |
That was actually one of the few good things about the abortive national spine
in the NHS.
There was, supposedly, a standard format for data exchange that would enable all
the disparate UK medical systems to talk to each other. (Un?)fortunateky, the
project collapsed under the weight of self-interested consultants and government
meddling, but if this data exchange format survives, we might still end up with
a decent system out of it.
Cheers,
Wol[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, September 07 2012 @ 01:35 PM EDT |
However, from a pure business mind, it wouldn't surprise me if the costs were
the most important factor.
You state:
Otherwise, the customer
or person who wants to run LINUX has to re-input years of data (that might be
$100,000's of thousands of dollars of man hours). So, upgrading to windows,
and paying the support costs of the software company who developed and maintains
their windows software, is cheaper by far vs moving to Linux with no
exactly compatible application to migrate to.
This is true for the
short term - maybe. If it is true, depending on the support costs and licensing
costs and actual reasonable move over costs - the long term pays between (rough
gut estimate) 1 and 5 years.
After that, the costs of staying with
Windows is the more expensive path.
If you doubt the long term costs,
speak with such individuals as Ernie Ball about his
actual real life experience in switching and the long term vs short term costs
impacted by the switch.
So yea... you have a very sound point for any
mind who does not care about the long term costs and only looks to the short
term costs.
On the other hand, I'd say a real problem with switching to
Open Source is finding out exactly what that software actually does. Is it
simply an inventory type software? If so, then switching doesn't pose any
particular problem.
However: if the software has a database that includes
drug types, side effects, conflicts, etc. that is - for example - populated via
some data path from some pharmacy that helps the Vet in determining drugs to
use, amounts of drug to dispense, etc. then that poses a very real problem that
isn't "short term vs long term money" related. If it goes further and tracks
the prescriptions for a particular patient and red flags questionable things
that the doctor is about to prescribe - that's an even more serious
concern.
Given drug dosages of the wrong amounts can easily kill - I'd be
extraordinarily cautious about suggesting a move away from their current
software before finding out exactly what that software does.
RAS[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, September 07 2012 @ 01:53 PM EDT |
As someone with a finger in the proprietary medical software market, I've
observed that more than a few of these vertical-specific apps use some sort of
RAD environment with its own database, such as Access/Jet, Clipper, FoxPro or
its Visual descendants. If you can get at the tables one way or another,
whether by ODBC or dbfdump or writing a dump script in the RAD language, and the
data's not encrypted by the application itself, you can generally construct a
script or query to export as much of the data in any form you like, subject to
the laws of diminishing returns and impedance mismatch.
Really, the customer cares most about their data. Most customers will entertain
spending some single-digit percentage of the annual TCO to have the records
ported mechanically rather than have their employees spending time re-keying
everything from one system to the other.
Point is: someone who buys software will bite the bullet and convert their data
when they find a clearly better-fit tool for working with it.[ Reply to This | Parent | # ]
|
| |
| Authored by: Tufty on Friday, September 07 2012 @ 10:07 PM EDT |
This may not be such a great issue in this situation though I do take the point
and it is a familiar issue. I won't get into their details but the list may not
be too large and there would be willing helpers for re-keying while a date
cut-off may be possible.
Thanks for the suggestions guys, I'm going to have a busy week-end.
---
Linux powered squirrel.[ Reply to This | Parent | # ]
|
|
|
|
|
