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

["Just Looking" <nospam@xxxxxxxxxx>]

By SQL I assume you mean Microsoft SQL, probably MSDE, not a generic
Structured Query Language running in a Server OS environment. Some high end
access systems say that they're database engine neutral and will use
anything. That is hype as far as I have seen.
If you have Microsoft SQL then you should be able to open the database with
Microsoft Access 2003 or greater. There might be a pass code for needed for
logging into (connecting to) the database. Access can switch from tables to
SQL script view so depending on what technique you like use to manage the
database, it should not be that difficult to do.
Again you have not said what brand of access control you are migrating from
or to, so it is hard to get into any real "how to" detail.  You keep on
mentioning alarm points. How many points are you talking about? I have seen
systems processing over 200,000 transactions alarms (like door held, door
forced, wrong access level, wrong time zone) per month. That took SCO UNIX
and an IBM Informix database to work, but you could still parse out the
tables with Microsoft Access and get reports with Crystal Reports. I am not
familiar with any other tools you may need to do a conversion of the
database. As far as vendor lock in, I have not heard of that on any access
control system other than normal password and data protection schemes.
Vendor lock in might not be legal to do in our state in any case.



"Pat Coghlan" <news@xxxxxxxxxx> wrote in message
news:46851f3c$0$7118$c3e8da3@xxxxxxxxxxxxxxxxxxxx
> Roland More wrote:
> > There is no EULA that would stop you from keeping your own data.
> > Do you know what database engine your new system as well as your old
system
> > uses? Hopefully it is not Borland, the king of data corruption in my
> > opinion. Even without using the data front end of the access application
> > itself, the data tables can generally be accessed. However, sometimes
the
> > alarm points are dealt with by a third party add on software overlay.
> > You have not mentioned any badging yet so I don't know if that is a
concern
> > too. If you wish to save yourself the time and trouble of repunching all
the
> > data, you will have to create a table from the data in the old system
that
> > matches the table format the new system uses. Generally those tables
have to
> > match exactly in all aspects (text and text length, dates and date
formats,
> > on and on). If you have not used been trained on databases this can be a
> > tough assignment. If you mention the brand of the old and new systems
the
> > techniques for doing it could be more easily explained.
>
> Old DB: SQL
> New DB: SQL
>
> The conversion could pretty much be operated, but this would require
> tools if we want to clone existing cardholder and zone information and
> insert into the new system.
>
> Although the "data" belongs to us, it might be hard to extract (short of
> cutting/pasting) without infringing on the EULA.  The practice is known
> as vendor "lock-in", e.g. software systems which manage patient medical
> data.  If the company/doctor stops paying the fees, the data remains
> inaccessible.