[futurebasic] Re: [FB] Database Front-End

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2008 : Group Archive : Group : All Groups

From: Brian Stevens <bstevens33@...>
Date: Sat, 19 Jan 2008 17:31:00 -0700
On Jan 19, 2008, at 5:03 PM, Robert Purves wrote:

> Christopher Wyatt wrote:
>> Brian Stevens wrote:
>>> Robert Purves wrote:
>>>>> Here's a complete FBtoC program that interacts, in a limited  
>>>>> but instructive manner, with SQLite.
>>>> Very nice Robert. Thanks for posting.  Which docs did you  
>>>> consult for calls? I'd like to look at this.
> Just the header file:
> /usr/include/sqlite3.h
Thanks Robert.

>> If things are pretty straightforward, we could create a framework  
>> for those interested in using SQLite. Combined with SQLite Manager  
>> or a similar tool, we'd have a nice database alternative to  
>> REALbasic. (Since SQLite Manager is an RB app, we could work  
>> towards replacing that, too... just a thought.)
> See the primitive demo
> <www.4toc.com/fb4/SQLite_in_FBtoC.zip>
> which creates a db and adds some data to it, calling the C API  
> directly as proof-of-concept.
> A set of FB wrapper functions, i.e. what you call a "framework", is  
> clearly required to make this usable.
>> In RB, queries are returned as a recordset, versus loading them  
>> into an array or using pointers. What approach or mix of  
>> approaches would work with FutureBASIC? I love FOR EACH using  
>> records, but there is a lot to be said for arrays with small queries.

My DBA background gives me an edge here even though I don't know what  
an RB record set is. Typically, a manager coalesces data from several  
tables as the result of a table join (in relational databases data is  
structured in rows and columns. These rows and columns are referred  
to as a table. Tables can be "joined" on common keys allowing related  
data (based on key(s)) to be retrieved programatically. RB's record  
set is probably a similar abstraction to provide a common delivery  
regardless of how simple or complicated the underlying joins.

Robert has given us a nice push here. Anyone want to take it further?

Brian S.