ODBC getting specific row

[Michael Clease]

I would like to see the thinBASIC community take a serious look at creating a ODBC extension module that is easy to use. Sooner or later you will need to move beyond spiffy games.

John if its that important to you then why dont you write the ODBC module?

Some people have no interest in ODBC, now you have pointed out my error I will rewrite my windows key revealer to use OBDC because thats just what it needs.

off to write somemore spiffy games now.

[John Spikowski]

John if its that important to you then why dont you write the ODBC module?

Michael,

I do very little development under Windows anymore. I use the MySQL C API interface for most my DB needs. I suggested the ODBC module for thinBASIC as it gives the Windows programmer a greater selection of client options and Microsoft includes the management tools as part of the OS.

Maybe I was a bit harsh with the "something more then games" comment but without DB support, it really limits thinBASIC's use for most utility based applications which I assume was the void thinBASIC was trying to fill. If the direction is something else, my apology.

John

[ErosOlmi]

TOPIC MOVED to ODBC specific forum.
_________________________________________________

In DBMS record position inside the DB has no meaning because the position where the record is stored is demanded to the DBMS engine. And decision to where to store data is subject to many factors: from DBMS engine rules to optimization factors.

What is important in order to be able to identify your data is a KEY: a value (or a set of values) used to retrieve or connect other info in the DBMS or in outside references. Usually an auto increment unique field counter maintained by the DBMS itself is enough. Many applications instead use counters plus personalized fields (like, for example, a RecordID) maintained by personalized counters: InvoiceNumber, OrderNumber, CustomerID, PaymentCode, ...
Once you have identified your main data with a SELECT statement returning just one row, you will use whatever ID stored in your main record to retrieve data from other source of info: related tables in the same or other DB or external info.

In designing DB, a great attention must be placed to KEYs and ID. In the posted example, record number should be replaced with the concept of KEY field so something like:
record 1 = mike
record 2 = eros
record 3 = frank
record 4 = roberto
record 5 = petr

should be replaced with something like
RECID, UserName, ...
1, mike, ...
2, eros, ...
3, frank, ...
4, roberto, ...
5, petr, ...

Where RECID is a unique identifier (in this case a DBMS maintained counter is OK) used to link every user with it's data and to other sub data in linked tables ( [wiki=Relational_model]Relational_model[/wiki]) or in external references.

I will try to write down an example using an auto increment counter and post here.

Regarding why I followed José way to interface with ODBC is exactly because it is low level interface with API and if you get it, you get ODBC in one go. After that you can write any wrapper. But if there will be real interest, I can think to write a specific thinBasic module.

Eros