Switching alarm system - can I convert my database?

Pat Coghlan wrote in news:00d044b6$0$28079$ snipped-for-privacy@news.astraweb.com:

Without knowing any specifics, all we can give is general advice. Does your current software have have any export functions? if you can export to excel or to a text file you might be able to cut and paste some of your information. Does your new software have a conversion utility?

you are probably still looking at some manual entry. No pain no gain

There is an export function for cardholders only, but we have lots of other data (alarm point descriptions etc. - thousands of them) that could be moved over.

Doing the conversion is not the problem. I'm wondering if it can be done in a way to avoid infringing the EULA - which seems to preclude this type of data mining.

Pat Coghlan wrote in news:468507fb$0$14502$ snipped-for-privacy@news.astraweb.com:

I really cannot tell you. Though it seems to me that the information to run your system is yours. as long as you are not using any of their information, and only mining out waht you had to put in in the first place you should be OK.

I will add that is my opinion and i could be wrong.

I'd like to know if there has ever been any litigation related to a company doing this type of data mining.

I would think that any history or zone descriptions or user number would be your property and as long as your not stealing any of the operating system's code you'd be ok. Especially since you 'can' output that stuff. You'd need to Google for some legal stuff though - lots of stuff on the net...finding it will be another thing.

or...call your attorney as ask...might cost you a few bucks (and he may not know shit anyway)

| >

| > I really cannot tell you. Though it seems to me that the information to | > run your system is yours. as long as you are not using any of their | > information, and only mining out waht you had to put in in the first | > place you should be OK. | >

| > I will add that is my opinion and i could be wrong. | | I'd like to know if there has ever been any litigation related to a | company doing this type of data mining.

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.

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" wrote in message news:46851f3c$0$7118$ snipped-for-privacy@news.astraweb.com...

Regardless what they wrote in the EULA, if the data is information you supplied, such as keyholder names, schedules, access privileges, that data belongs to you. The people who wrote the software cannot claim title to it nor can they do anything to prevent you from "mining" it back from the database.

The copyright associated with a software product is there to protect the author against unauthorised use of his product. It doesn not grant him title to your information, regardless how his product encodes and stores it.

This is analogous to buying a file cabinet. The designer of the cabinet has the right not to have you copy his design and market it. But the files in it belong to you. Going one step further, if you're old enough to recall Cardex file systems, you'll remember the ingenious method used to select and sort cards using metal rods. The design was created in the 50's and remained in use into the early 70's. You could not copy the design or even make your own cards (though presumably lots of people did). The cards and the rod sorting system were patented. But the data on the cards was not the property of Cardex. That belonged to whoever typed it onto each card. Modern databases are far more sophisticated than Cardex. But the legal principles concerning them and the data they hold have not changed much in the last 50 years.

tools if we want to clone existing cardholder and zone information and insert into the new system.

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.

Vendor "lock-in" is a technique which database authors sometimes use to force users to keep paying. It's legal but it doesn't grant the vendor ownership of the data.

There's discussion of two relevent cases in ECommerce Times which sheds some light on the subject. Here's the URL:

In the first case the issue was ownership of data which the database *users* compiled. The court found that the data was not the property of the author. The second case was quite different. There the plaintiffs wanted access to data which another firm (the PGA Tour) had collected and entered. The court rightly found that the party which entered the data owned the data. The plaintiff was claiming he data was public domain. The court said they no.

As to hacking the database to get your data, there's no law against that. If you were hacking to make use of the software itself it would be a different story.

tools if we want to clone existing cardholder and zone information and insert into the new system.

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.

Here's an excerpt from a related case:

"Wiredata sued the municipalities in Wisconsin state court in an attempt to force them to divulge the data; those suits are still pending. Alarmed by Wiredata's actions, AT brought suit against Wiredata to stop it from demanding that the municipalities give it access to the data. AT also sought to enforce its copyright, claiming that the data cannot be extracted without infringement of its copyright or theft of its trade secrets."

"The U.S. District Court for the Eastern District of Wisconsin held for AT and issued a permanent injunction on the basis of AT's copyright claim alone, without reaching the trade secret claim. On November 25,

2003, however, the U.S. Court of Appeals for the Seventh Circuit (Judge Richard Posner writing the opinion for the three judge panel), reversed and remanded with instructions to vacate the injunction and dismiss the copyright claim, holding that extracting the data from the database incorporated does not constitute copyright infringement."

The appelate court essentially said that the author of the database has no property rights to the data stored in it. In short, go ahead and extract your data. It's not a problem.

Thanks for the info.

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.

This is such a f>> There is an export function for cardholders only,

You're most welcome.

really no other

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.

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.

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: