With this type of product it really depends whether the vendor is using the DBMS as a mere data storage facility with all the manipulation carried out by the client application, or if they are building a robust database. Broadly speaking, it should be impossible for a client application to affect the integrity of the data in a database. This involves a level of 'intelligence' being built into the database itself, in the form of triggers, functions and transactions. When a database is designed in this way it takes a large amount of work to move it from one DBMS to another, because all differ in the implementation of these features (despite SQL, which is reasonably standard). This being the case, it would probably be better if companies would focus on supporting one commercial and one open source (or at least freely available) DBMS. All the best, Nial. At 05:59 24/01/2002 +0000, you wrote:

Our `Database Server' from our business products range is IMB's DB2 on top of the SuSE Linux Enterprise Server, and has been available for a while.

http://www.suse.co.uk/uk/products/suse_business/database_server/index.html

We also resell Adabas

http://www.suse.co.uk/uk/products/software/databases/adabas/index.html

Both these are third party and under commercial licences.

However, going back to the earlier posts in this thread, the more people shout at the vendor about the meaning of `any', the better.

On Mon, 21 Jan 2002, Chris Puttick wrote:

...

Try Borland Interbase OE - much higher performance than MS SQL Server, with the assurance of a big brand name and option of paying for support. Also SuSE do a database solution...

BTW, how much is that costing, and have they committed to it?

--

------------------- Roger Whittaker SuSE Linux Ltd The Kinetic Centre Theobald Street Borehamwood Herts WD6 4PJ

------------------ 020 8387 1482 ------------------ roger@suse.co.uk ------------------

-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com

On Thu, Jan 24, 2002 at 11:54:32AM +0000, Nial wrote:

With this type of product it really depends whether the vendor is using the DBMS as a mere data storage facility with all the manipulation carried out by the client application, or if they are building a robust database. Broadly speaking, it should be impossible for a client application to affect the integrity of the data in a database.

Agreed, it's the principle behind using a 3-tiered architecture.

This involves a level of 'intelligence' being built into the database itself, in the form of triggers, functions and transactions.

Dependent on the complexity of the data, a good database designer should not have to resort to complicated stored procedures, triggers etc. You should design the database so that it's integrity is largely ensured by key constraints & choosing the right data types for the fields of your tables. A database for a school should not have to be overly complicated, but the front-end application can of course be as complicated as you like & there's no reason why you can't constrain data-input or queries in the client application.

When a database is designed in this way it takes a large amount of work to move it from one DBMS to another, because all differ in the implementation of these features (despite SQL, which is reasonably standard).

That's right.

This being the case, it would probably be better if companies would focus on supporting one commercial and one open source (or at least freely available) DBMS.

It would be better if they didn't rely on implementation specific features of SQL and they adhered to strictly using a 3-tiered approach with a reasonably simple 2nd tier so that any SQL-compliant DB can be used, either open source or commercial. The fact that these people have chosen not to do so, indicates to me that they have little clue as to how to design a RDBMS or more likely they've decided to say `to hell with it' & use implementation specifics in order to speed development ie. bodge it. Or yet another possibility is that they have done it right but haven't gone the last mile in order to allow it to work with other databases. It should be able to work with postgres, DB2 & others aswell - as they all support the major features of SQL. They need poking with a sharp stick by customers saying `Your product doesn't work with my database/OS. Good day to you.' Like any company they're demand led, so I'd encourage the original poster to get out his sharp stick & give them a prod ;) -- Frank *-*-*-*-*-*-*-*-*-*-* Boroughbridge. Tel: 01423 323019 --------- PGP keyID: 0xC0B341A3 *-*-*-*-*-*-*-*-*-*-* http://www.esperance-linux.co.uk/