Mary

You are correct - it's that sort of thing that can make transferring data
from one system to another very complicated, but can make it much faster.
I worked once with an SQL guru who took one look at the new system's
'import from brand x' function, decided the import run would take 27 hours
a day for several weeks, and did it all with SQL in less than a day. But
he knew both systems intimately.

It is also why 'customising' systems at the database level isn't always a
good idea. Even if you stick with the same vendor, an upgrade will
probably see you in a mess, and having to re-do the customisation, and /
or be unable to use whatever conversion programs come with the new
version.

And your BIG plus, score ten out of ten, red star on the back of your hand
and go home early for the day, is that anything SQL will be a much better
long term proposition. Eg does your RM system have inadequate reporting
facilities? if it's SQL, use Crystal Reports. Vendor gone out of business?
If it's SQL, hire a good SQL programmer and limp along for long enough to
get a new system. Want an interface to your Accounts system? if both are
SQL it's a lot easier. SQL should be a mandatory for all system specs.

All you have to worry about then are the subtle differences between each
vendor's SQL.

Cheers

Glenn

Glenn Sanders MRMA
[log in to unmask]
[log in to unmask]
Australia

These views are mine alone. They may or may not be those of any
previous or present employers or clients. I don't know. If I'd asked
and they'd agreed, I would have signed it "Bloggs and Co and
Glenn". Or whatever. But I haven't, so I didn't.

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance