Subject | Re: [IBDI] Re: Porting from MS SQL Server 7.0 to Interbase |
---|---|
Author | Helen Borrie |
Post date | 2000-06-25T07:04:52Z |
At 04:43 AM 25-06-00 +0000, you wrote:
"funkyshonality" as SQLServer is. I've worked with both (simultaneously,
using the same client) and, to me, the nearer one is to standard SQL the
better I like it. "Purity is simplicity". And small server and client
footprint.
in the client/server market. It has never done better than 29 per
cent. It's just not worth it.
"Compatibility" with Access doesn't make any sense. So much of Access is
dependent on its physical structure - it's a big part of why its SQL is
such an abomination. Anyway, I've converted Access databases to InterBase
and it was no pain. It certainly doesn't warrant corrupting IB with a
busted dialect.
From experience, I can tell you that converting from Access to MSSQL
Server is no Teddy Bears' Picnic. SQL Server to InterBase isn't that hard,
either; it's much harder in the opposite direction. The big differences
going from MS to IB come in the simplification of SPs and trigger code
(because IB allows multiple, prioritised triggers), the need (sometimes) to
write new UDFs and the funny, dangerous habits that people acquire when
they rely on autoincrement fields and inbuilt functions to patch up a bad
data model. Porting a bad data model is never a great idea.
offering good documentation and transition support do the conversion thing,
without needing to break the database architecture or overload the engine
with redundant support. Those of us who chose InterBase did so because it
does a great job without any nursemaiding. The fatter and uglier the
"competitiors" become, the more attractive becomes the unfettered elegance
of InterBase. If the company does its part right, we have nothing to fear
except customers' intractability (and maybe the thousands of $$$ spent by
M$ developers on all those books and MS***certificates!!)
because the Borland compiler lacks something (I forget what, now) in ANSII
compatibility; or did once upon a time when important decisions had to be
made...
Helen
http://www.interbase2000.org
___________________________________________________
"Ask not what your free, open-source database can do for you,
but what you can do for your free, open-source database."
(J.F.K.)
>Thats true -- but we have to ask ourselves this -- is the aim ofI certainly would like it less if it was as fraught with non-standard
>Interbase to be the "purest" database, or make it easy so that the
>more people join up, the better. I'd like to point out that Oracle
>and Sybase also support "+".
"funkyshonality" as SQLServer is. I've worked with both (simultaneously,
using the same client) and, to me, the nearer one is to standard SQL the
better I like it. "Purity is simplicity". And small server and client
footprint.
>The new dialect approach is a very good idea. I would suggest aDon't fall into the trap of believing the myth that SQL Server is dominant
>dialect for MS Access/SQLServer compatibility. If Interbase had 90%
>compatibility with MS Access and had a Access Upsizing Wizard,
>Interbase would convert lots of users when Access started to have
>scaling problems.
in the client/server market. It has never done better than 29 per
cent. It's just not worth it.
"Compatibility" with Access doesn't make any sense. So much of Access is
dependent on its physical structure - it's a big part of why its SQL is
such an abomination. Anyway, I've converted Access databases to InterBase
and it was no pain. It certainly doesn't warrant corrupting IB with a
busted dialect.
>Currently Access users are going for MS SQL Server when they hitIn Microsoft's dreams!!
>scaling problems.
From experience, I can tell you that converting from Access to MSSQL
Server is no Teddy Bears' Picnic. SQL Server to InterBase isn't that hard,
either; it's much harder in the opposite direction. The big differences
going from MS to IB come in the simplification of SPs and trigger code
(because IB allows multiple, prioritised triggers), the need (sometimes) to
write new UDFs and the funny, dangerous habits that people acquire when
they rely on autoincrement fields and inbuilt functions to patch up a bad
data model. Porting a bad data model is never a great idea.
>Similarly, a MySQL compat mode would do wonders to Interbase's marketIf the company cares enough about market share, it has far more to gain by
>share.
offering good documentation and transition support do the conversion thing,
without needing to break the database architecture or overload the engine
with redundant support. Those of us who chose InterBase did so because it
does a great job without any nursemaiding. The fatter and uglier the
"competitiors" become, the more attractive becomes the unfettered elegance
of InterBase. If the company does its part right, we have nothing to fear
except customers' intractability (and maybe the thousands of $$$ spent by
M$ developers on all those books and MS***certificates!!)
>This is proof that Microsoft is too dominant for its own good! Even aApparently, it's not because msvc++ is a "dominant" (is it dominant?), but
>borland product uses MS Visual C++!
because the Borland compiler lacks something (I forget what, now) in ANSII
compatibility; or did once upon a time when important decisions had to be
made...
Helen
http://www.interbase2000.org
___________________________________________________
"Ask not what your free, open-source database can do for you,
but what you can do for your free, open-source database."
(J.F.K.)