Thanks , Simon Stuart , but I'm not that optimistic about Delphi, but I promised to limit trolling (and that would be the purpose of a big explanation ;)
Hi Olivier. I'm your counterpoint then. I'm not that optimistic about .net. I am very glad I never made much investment in WPF and Silverlight, for instance. Delphi has had its series of Dead sub-technologies too, and stuff that stays in the default install but should have been removed a decade ago, like the BDE. :-)
Dmitry Filimonov : I don't deserve your congratualtions : As I explained I did not really choose Delphi, I choose the project ;) I have 15 years of experience in software development, and as Lars Fosdal says, I prefer to see myself as a general software producer either than an evangelist in any language.... After all , a garbage collector is a garbage collector wherever platform it runs ... oops, I trolled
Lars Fosdal, we've been using ADO for 13 years and I don't see any reason to switch to dbExpress, even though we are using the dbExpress based DataSnap. When talking to SQL Server, dbExpress uses the same OLEDB provider that ADO uses.
Passing the db connection directly to the client looks nice at times, but I can image some fairly ugly code if we let our team do something like that. :)
Please Lars Fosdal elaborate more on your ADO (a.k.a. dbGo) vs dbExpress experience. If dbExpress uses the same system db connection library msado*.dll as Jon Robertson states, what is the real difference between these two db access technologies in case of SQL Server? You've asked similar question back to https://plus.google.com/101151078020673275690/posts/fg2QBnxVmQQ Have you sharped the answer for yourself? Wikipedia article http://en.wikipedia.org/wiki/DbExpress mentions unidirectional only data access.
No, not really. I started to do a new wrapper around the dbExpress that mimicked our fairly thin ADO wrapper, but I got stuck on issues with transactions (multi level) and also some minor hitches with the parameterization of stored procs. One thing I noticed was that our wrapper had a severe start up penalty compared to the ADO connection, but that may very well be my wrapper and not dbExpress's fault.
A brief description: We have a connection pool, which is supposed to be thread safe, limiting a connection to be used within a specific thread. Once the thread is done, the connection is discarded. This works well with ADO, but I may need to rethink this for dbExpress, to share connections between threads to avoid reconnecting new dbExpress connections all the time.
Time constraints and "don't fix it if it ain't broken" have put the migration from ADO to dbExpress on hold for now. It is still on my need to do (eventually) list, though.
So why move? Well - eliminating the extra COM based ADO layer is one goal. The other is as Jon Robertson points out - that the new and fun stuff is.
Also - and correct me if I'm wrong - there are third party dbExpress drivers that talk native TCP with the db host, completely removing the OLEDB layer - which to me sounds like a good thing. Another layer of abstracts gone.
And I promise to avoid (as much as possible) trolling ;)
ReplyDeleteYou might be one in a million, cause usually it goes the other way round.
ReplyDeleteI switched because of a professional opportunity : I've chosen a more intersting project in Delphi to something less interesting in C#
ReplyDeleteThat's a compelling reason. As Software Developers, we are mainly carpenters, and we do need to be able to handle more than one tool.
ReplyDeleteAlthough, with Delphi, you can nail anything ;)
Thanks , Simon Stuart , but I'm not that optimistic about Delphi, but I promised to limit trolling (and that would be the purpose of a big explanation ;)
ReplyDeleteHi Olivier. I'm your counterpoint then. I'm not that optimistic about .net. I am very glad I never made much investment in WPF and Silverlight, for instance. Delphi has had its series of Dead sub-technologies too, and stuff that stays in the default install but should have been removed a decade ago, like the BDE. :-)
ReplyDeleteGot rid of the BDE, but now we're sort of stuck with ADO, when we should have been on dbExpress :P
ReplyDeleteOlivier, You're the man! Kudos! ;)
ReplyDeleteDmitry Filimonov : I don't deserve your congratualtions : As I explained I did not really choose Delphi, I choose the project ;) I have 15 years of experience in software development, and as Lars Fosdal says, I prefer to see myself as a general software producer either than an evangelist in any language.... After all , a garbage collector is a garbage collector wherever platform it runs ... oops, I trolled
ReplyDeleteGarbage collectors, hah! People say, Delphi will have soon the reference-counted objects, same as at Objective-C.
ReplyDeletehttp://en.wikipedia.org/wiki/Objective-C#Automatic_Reference_Counting
That would be a nice thing ..... I hope my actual company, which jumps from Delphi 4 to Delphi XE2 , will not wait 15 years again .... ;)
ReplyDeleteLars Fosdal, we've been using ADO for 13 years and I don't see any reason to switch to dbExpress, even though we are using the dbExpress based DataSnap. When talking to SQL Server, dbExpress uses the same OLEDB provider that ADO uses.
ReplyDeletePassing the db connection directly to the client looks nice at times, but I can image some fairly ugly code if we let our team do something like that. :)
Please Lars Fosdal elaborate more on your ADO (a.k.a. dbGo) vs dbExpress experience. If dbExpress uses the same system db connection library msado*.dll as Jon Robertson states, what is the real difference between these two db access technologies in case of SQL Server? You've asked similar question back to https://plus.google.com/101151078020673275690/posts/fg2QBnxVmQQ Have you sharped the answer for yourself? Wikipedia article http://en.wikipedia.org/wiki/DbExpress mentions unidirectional only data access.
ReplyDeleteNo, not really. I started to do a new wrapper around the dbExpress that mimicked our fairly thin ADO wrapper, but I got stuck on issues with transactions (multi level) and also some minor hitches with the parameterization of stored procs. One thing I noticed was that our wrapper had a severe start up penalty compared to the ADO connection, but that may very well be my wrapper and not dbExpress's fault.
ReplyDeleteA brief description: We have a connection pool, which is supposed to be thread safe, limiting a connection to be used within a specific thread. Once the thread is done, the connection is discarded. This works well with ADO, but I may need to rethink this for dbExpress, to share connections between threads to avoid reconnecting new dbExpress connections all the time.
Time constraints and "don't fix it if it ain't broken" have put the migration from ADO to dbExpress on hold for now. It is still on my need to do (eventually) list, though.
So why move? Well - eliminating the extra COM based ADO layer is one goal. The other is as Jon Robertson points out - that the new and fun stuff is.
Also - and correct me if I'm wrong - there are third party dbExpress drivers that talk native TCP with the db host, completely removing the OLEDB layer - which to me sounds like a good thing. Another layer of abstracts gone.