Re: Switching alarm system - can I convert my database?

[Pat Coghlan <news@xxxxxxxxxx>]

XML training is one thing that I've had in the back of my mind for some
time :-)

I asked the H/W guys to capture some sample data in text form for a
couple of the zones in a building and try to map it to equivalent
objects (intelligent controllers, inputs, relays etc.) on the new
system, with the long-term goal being to automate this somehow (similar
to the XML export/import you were talking about).  The exercise was a
real eye-opener, and they realized that a lot more of the new gear will
be required than previously thought.  They're leaning towards starting
from scratch (i.e. redo all the data entry), but with tens of thousands
of descriptions for inputs, zone names etc., we really need to automate
this.

-Pat

Robert L Bass wrote:
>> Thanks for the info.
>
> You're most welcome.
>
>> I guess the only point in question is whether
>> one has the right to use the table structure
>> (field names etc.) to interpret the data and relationships.  I mean,
>> there's really no other
>> way to do this efficiently.  It's not practical to
>> dump out all the tables and start piecing the
>> information bits back together.
>
> The data structure (relationships between tables,
> etc.) is the property of the author of the database.
> The data itself is yours since you (or your staff)
> created it, entered it into the program and
> maintained it.
>
> However, any new database you decide to use
> will necessarily have its own relational structure.
> If the chosenb software platform can import and
> export XML files you'll be much better off.  That
> will make your data more transportable now and
> in the future, should you ever decide to change
> again.
>
> We use XML in other security related application
> software as it is the most transportable and
> configurable of current formats.  Not every
> developer uses XML though.  You might want to
> inquire of the vendor you're considering using
> before you make a final selection.
>
> One of the nice things about XML is you can
> write into the schema the rules, such as
> limits, options and relationships between
> columns and tables.  Once you've got the
> schema the way you wabnt it, it's easy to
> massage tabular data from any software to fit
> the needs of another app.
>
>> This is such a fine point, though, so I doubt
>> any vendor is going to try and stop a customer
>> from extracting the information.
>
> You don't really need the relationships -- just
> the raw data and some knowledge of the way
> the new app needs it formatted.
>
> If the job is large enough to merit the cost, you
> might consider hiring someone experienced in
> database integration to do the project for you.
> If that's of interest let me know.  I have people
> on staff who do that sort of thing on a regular
> basis.
>