Possible new open-source pb library

[Don Dickinson]

In the past i've written wrappers (and released free on my web site) for various database engines ... sqlite2, sqlite3, mysql, mssql. I am considering unifying them into one generic wrapper. This would be similar to the PDO library in PHP.

For example, when you initialize the engine, you can specify (via constant) which engine(s) you will be using and when you connect to the database, you specify what kind of database engine you're talking to. For example.

unidbInit %UNIDB_SQLITE3 or %UNIDB_MYSQL
hDB = unidbConnect(%UNIDB_MYSQL, "hostname", port, user, password)
'- do some sql stuff here
unidbDisconnect hDB
unidbUninit

This allows the same code (save the first parameter of the unidbConnect function) to be the same regardless of the database engine.

Anyway, i was thinking of open-sourcing the project (hosted on my subversion server), opening it up to community development after i have the base framework in place, and making it public domain.

Anyone interested in something like this - either using or contributing or?
I might seek help in adding support for sqlLightning and ODBC at some point down the road. I have a wrapper for odbc that i have not released to the general public, but it needs work. i haven't used sqllightning, but it looks darn cool (thanks fred/paul/etc).

best regards,
don

[Mike Doty]

Yes, I would be interested.

Anyone interested in something like this - either using or contributing or?

http://www.powerbasic.com/support/pb...ad.php?t=38980 (ddoc)

[Guenter Fuessner]

That could/should interest almost anybody …

[Bern Ertl]

Hi Don,

It sounds like a neat idea - allowing end users to choose the back end DB they prefer. Do you know how compatible the SQL implementation is amongst the supported databases? I know SQLite, for example, lists features of the SQL system that they don't support or handle differently from other SQL implementations. If the other databases have similar quirks, it may render the universal interface moot.

BTW, I'm developing a project with SQLitening right now and so far, the system is fantastic.

[Don Dickinson]

some database servers offer different features ... such as sqlite's attaching of external databases. some offer different flavors of sql ... e.g. mssql has TOP and mysql/sqlite uses LIMIT. The sql differences aren't a big deal - it is up to the programmer to deal with them. the other features, however, will likely lead to extra function calls specific to the engine. i'm going to start by building a framework around the basics ...

connecting, disconnecting, executing an sql statement, retrieving resulting rows/columns, executing an sql statement that returns a single result row to indicate success or failure of INSERTs, DELETEs, UPDATEs. Frankly, 99% of the database calls i make are these specific things. i'll handle the extra features after the framework is built.

for those that think "isn't this a recreate of odbc" ... well, i guess it is, but if you've had to deal with odbc drivers for either sqlite or mysql you might see the need for a different abstracted native access. the fact is that the odbc drivers were written from the perspective of "we we have to force the native access method to be abstracted within this existing specification". i am doing the opposite ... *creating* the abstraction to wrap up the native access ... making the abstraction with native access for sqlite, mysql, and mssql in mind.

best regards,
don

thanks
don

[Tom Cone Jr]

I'm curious how this might be similar to or different from something like SQL Tools?

[Michael Mattias]

Seems to me OLE+ADO and ODBC already provide common, abstracted interfaces to multiple DBMSs, other than the "connection string"

It sounds like you want to re-invent the wheel.

What am I missing here?

MCM

[Mike Doty]

Direct access databases, Btrieve, dBase, SQL, any self-made indexing system and any protocol the programmer wants could be used.
No run-time licensing fees, much smaller foot-print, no additional installation files, less memory usage, very fast, you control source code.
Secure email, no need for FTP, chat, bulk messaging ....

[Bern Ertl]

Seems to me OLE+ADO and ODBC already provide common, abstracted interfaces to multiple DBMSs, other than the "connection string"

What am I missing here?

The devil is in the details.

Instead of adding an abstraction layer (or two) that preprocesses database access statements, he's essentially proposing a wrapper that merely routes database access calls to the native APIs for a few select db systems.

You would not need to to install ODBC drivers or mess with the COM/OOP for OLE+ADO.

[Michael Mattias]

If DBMS has ODBC driver is available, you can use ADO even if there is no DSN by using the MS-Default OLE provider and specifying the driver name ib the connection string. (http://www.codemaker.co.uk/it/tips/a...essConnections)

(I have fallen in love with ADO. It think this might be The Real Thing).

While not having an ODBC DSN set up for each possible database in use would be common (especially when testing/developing), it would seem strange to me to NOT have at least the ODBC driver installed if you've installed the 'DBMS of interest.'

Besides, ADO is not that difficult. Start with this: Generic 'ADO' Connection and Query Tester (CC 5+/Win 9+) 11-02-08 ... and the rest is really straightforward.

Of course, I am presupposing a knowledge of basic SQL, but these days I would think that almost mandatory for anyone claiming to be a developer of database applications.

[Don Dickinson]

here's what you're missing ... i use three dbms's (99% of the time anyway)... sqlite, mysql, and mssql. MSSQL has excellent odbc support (very fast, stable, bug-free). but, sqlite and mysql's has not been nearly as good in my experience. that's the bottom line. it may be of no use for others or people who don't use sqlite or mysql a lot.

-don

[Mike Doty]

Don,
Hope you are integrating with ddoc or print/preview.