en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en pt en en en en en en en en en en en fr de es en en en en nl en en en en en en en en es en en en en nl en en en en en de en en en en nl en en en en en de en en en en en en en en nl en en en en en en en en en en fr en en en en en en en nl en en en en en en en en en en nl vi en en en en en en en fr en da en en es en en en en nl en en en en en en en en de en en en en nl fr en en en en en en en de en en en en en en en en nl en en en en en en en en en fr en da en en en en en en en nl en en en hbs_lat en fr en en es en en en en nl en en en en en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in Third-Party Forums only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Possible new open-source pb library
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
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.
hDB = unidbConnect(%UNIDB_MYSQL, "hostname", port, user, password)
'- do some sql stuff here
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).
Join Date: Feb 2005
27 Feb 2009, 12:17 AM
Yes, I would be interested.
Anyone interested in something like this - either using or contributing or?
Last edited by Mike Doty; 1 Mar 2009, 08:43 AM.
Join Date: Jul 2008
27 Feb 2009, 05:40 AM
That could/should interest almost anybody …
Join Date: Dec 2000
27 Feb 2009, 08:57 AM
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.
Join Date: Nov 2002
27 Feb 2009, 10:34 AM
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.
Join Date: Mar 2005
27 Feb 2009, 08:46 PM
I'm curious how this might be similar to or different from something like SQL Tools?
Join Date: Aug 1998
28 Feb 2009, 02:31 PM
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?
Port Washington WI USA
Join Date: Feb 2005
28 Feb 2009, 02:34 PM
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 ....
Last edited by Mike Doty; 1 Mar 2009, 08:44 AM.
Join Date: Dec 2000
1 Mar 2009, 08:27 AM
Originally posted by Michael Mattias View Post
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.
Join Date: Aug 1998
1 Mar 2009, 09:52 AM
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.
Port Washington WI USA
Join Date: Nov 2002
1 Mar 2009, 08:12 PM
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.
Join Date: Feb 2005
2 Mar 2009, 01:04 PM
Hope you are integrating with ddoc or print/preview.
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 04:49 AM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.