ADO-VO
in [Visual Objects]
|
Prev: VOCOM for VO 2.8
Next: RP214 not working
From: Geoff Schaller on 22 May 2007 18:04 Phil, What you say is correct but you are missing the key point about using ADO and an OLEDB provider. Except for connection strings and some minor syntax differences, the purpose of using OLEDB is so that when I write code for mySQL, the same code will work to Oracle and Sybase. When you use direct API calls your code is fixed to that API totally and if you now want your app to work against a different DBMS, you are up for a major rewrite. So if the assumption is that your application will only ever work to PostGre then yes, the api approach is fine but then that is a little bit limiting. We already have MS SQL, DB2 and now an Oracle client but my base data classes don't have to change. The code we wrote for DB2 (our first dbms) now works against MS SQL perfectly and only some minor tweaking is required to make it work against Oracle. This is not a hack at mySQL or PostGre - it is about the general approach that developers should consider when designing their platforms and code libraries. If you are writing a totally stand-alone app to only one DBMS then there are grounds to consider the API approach. If your future is not that hard and fast and you want the ability to consider other DBMS then I would recommend OLEDB. Geoff "Sherlock" <sherlock(a)sherlock.com.au> wrote in message news:1179835122.079497.114300(a)u36g2000prd.googlegroups.com: > James, > > snip[ If you have a choice, abandon MySQL for PostGre.] > > You do not NEED an OLEDB providor because with mySQL and PostGRES you > can do it natively with a DLL both of these SQL engines provide. One > VO 3rd party providor is releasing a mySQL + PostGres or either engine > written round the dataserver class.. so the syntax can be as close to > DBserver or SQL > I believe they are writing the documentation for it and I tested it a > few months ago. > I understand the source will be made available as well. > > We have been using VO with the native DLL for years and have been > experimenting for Desktop development with PostGres and we have one of > Delphi systems running with it now. > > Phil Mc Guinness
From: James Martin on 23 May 2007 07:45 Thanks for the advice. Thing is, I would like to get my feet wet before I invest. I have used ODBC to get data from Access databases, and the speed was really not practical. James "Geoff Schaller" <geoff_(a)software_objectives.com.au> wrote in message news:46536906(a)dnews.tpgi.com.au... > Phil, > > What you say is correct but you are missing the key point about using ADO > and an OLEDB provider. Except for connection strings and some minor syntax > differences, the purpose of using OLEDB is so that when I write code for > mySQL, the same code will work to Oracle and Sybase. > > When you use direct API calls your code is fixed to that API totally and > if you now want your app to work against a different DBMS, you are up for > a major rewrite. > > So if the assumption is that your application will only ever work to > PostGre then yes, the api approach is fine but then that is a little bit > limiting. We already have MS SQL, DB2 and now an Oracle client but my base > data classes don't have to change. The code we wrote for DB2 (our first > dbms) now works against MS SQL perfectly and only some minor tweaking is > required to make it work against Oracle. > > This is not a hack at mySQL or PostGre - it is about the general approach > that developers should consider when designing their platforms and code > libraries. If you are writing a totally stand-alone app to only one DBMS > then there are grounds to consider the API approach. If your future is not > that hard and fast and you want the ability to consider other DBMS then I > would recommend OLEDB. > > Geoff > > > > "Sherlock" <sherlock(a)sherlock.com.au> wrote in message > news:1179835122.079497.114300(a)u36g2000prd.googlegroups.com: > >> James, >> >> snip[ If you have a choice, abandon MySQL for PostGre.] >> >> You do not NEED an OLEDB providor because with mySQL and PostGRES you >> can do it natively with a DLL both of these SQL engines provide. One >> VO 3rd party providor is releasing a mySQL + PostGres or either engine >> written round the dataserver class.. so the syntax can be as close to >> DBserver or SQL >> I believe they are writing the documentation for it and I tested it a >> few months ago. >> I understand the source will be made available as well. >> >> We have been using VO with the native DLL for years and have been >> experimenting for Desktop development with PostGres and we have one of >> Delphi systems running with it now. >> >> Phil Mc Guinness >
From: Carlos Rocha on 23 May 2007 10:23 James, > ... I have used ODBC to get data from Access databases, and the speed > was really not practical. > That's Access fault, not ODBC. -- Carlos Rocha
From: James Martin on 23 May 2007 13:24
Can you tell me where to get these DLLs? I would appreciate knowing about them. James "Sherlock" <sherlock(a)sherlock.com.au> wrote in message news:1179835122.079497.114300(a)u36g2000prd.googlegroups.com... > James, > > snip[ If you have a choice, abandon MySQL for PostGre.] > > You do not NEED an OLEDB providor because with mySQL and PostGRES you > can do it natively with a DLL both of these SQL engines provide. One > VO 3rd party providor is releasing a mySQL + PostGres or either engine > written round the dataserver class.. so the syntax can be as close to > DBserver or SQL > I believe they are writing the documentation for it and I tested it a > few months ago. > I understand the source will be made available as well. > > We have been using VO with the native DLL for years and have been > experimenting for Desktop development with PostGres and we have one of > Delphi systems running with it now. > > Phil Mc Guinness > > |