Missing the point again - i think

[Pascaluvr]

OK, I am sure I have missed something, so please help my thought process.

In the 'old days', programs were designed around the data (bases) - the Form was just a high level layer to display the data - but with Lazarus (Delphi) it seems that the program is designed around the Form and the database has become tightly interwoven with the Form itself.

As an example, I find that my Form.units are getting extremely large, as database navigation is basically restricted to the Form.unit itself, rather than in a lower level unit where i can have Procedures and Functions to, say, Get_Customer_Details, Get_invoice_items, etc.

I see 2 solutions:
1) Pass Connection, DataSource, Transaction, Query, etc as parameters to the lower level functions
or
2) Define the above components in the lower level Units (and miss out on the many automatic features of Lazarus - such as Data-Aware, auto Create - Free, etc).

So I am sure I am missing something - every time i have a question like this there always seems to be a simple solution - what am i missing this time?

Thanks in advance

[BigChimp]

1. You can put your connections etc in data modules to tidy things up and share between forms.
2. There's nothing stopping you using "lower level" code like the code here
http://wiki.lazarus.freepascal.org/Database_bug_reporting#FreePascal

in your Lazarus project along with GUI code. You can use your own connection etc object or you can use the query object defined by the gui to execute SQL etc.

Having forms with drag and drop database connectors etc is indeed the "new"/RAD way.

Once things get more complicated/large, splitting them out (e.g. to data modules, or even low level code that provides objects that form code can use to fill GUI controls - which are not data-bound this time) are often used.

You can even use frameworks that abstract away database access and presents you with objects. Look e.g. at tiOPF; presumably also Greyhound (haven't looked at that one yet)

[Pascaluvr]

Thank you Big Chimp - you are always tolerant of my stupid questions...  but i'm afraid i still don't get it.  If i move the connection away from my form, what does Lazarus 'buy me' over and above using something like SQLiteWrap?

Sorry for being so thick!

[BigChimp]

Ah you mean http://www.ararat.cz/doku.php/en:sqlitewrap?

1. Moving the connection away from a form to a data module does not fundamentally change the way Laz works: it remains RAD. It's just easier to share the same connection and queries across multiple form.
You remain able to drag and drop data-aware controls. AFAIU, you can also easily synchronize position of data aware controls (eg two grids on separate forms) using a single datasource on the module.
(That said, haven't used data modules in anger... am more of a command line coder than a GUI guy, I'd think)

2. If you do go further and use non-gui code to convert db access to objects as mentioned above, then it buys you nothing except the built in sqldb access layer is built in, and allows switching between sqlite3 and other dbs fairly easily.

Summary:
1. If you have an application with multiple forms, look into putting stuff on your data module so you don't need to keep up setting new connection objects etc.
2. If your project gets really complicated/big, RAD development is often not the best fit, and you might want to convert db access/data to business objects, perform validation, caching, etc. But that's only for big, complicated projects. Or if you really like that way of working

Hope this clarifies a bit what I meant & hope others will chime in with their experiences...

[Pascaluvr]

big chimp.
Thank you for the response.   Not  sure if this is a big application...   but  it certainly  aint small.  It is to record horse racing..  so many tables = Courses, Races, Fields, form, Results .. etc  (there's more ... but you get the idea).  Clearly,   every Table links to another.  All DB info is downloaded from the web ...   there is NO user input, so that makes for one simplification.

The complications arise because for any race there is more info than fits on any screen.  That's ok, I can use Tabs for that.

I need to keep several active tables at any time.

Something like DBGrid makes display of some data easy - but there are other areas that makes specific data access absolutely  necessary - tieing it all together is still a challenge.

OK....   so that's where I am coming from...   and i still think a wrapper might be the way to  go.


Thanks for your responses to date

[BigChimp]

Hi Pascaluvr,

Thanks a lot for posting some background - often helps to talk about specific things rather than vague generalities [though I'm best at that]
I'm going to repeat myself a bit and ask some nasty questions - hope you don't mind...

I need to keep several active tables at any time.

You might put the queries/datasources into a datamodule as said.

Something like DBGrid makes display of some data easy - but there are other areas that makes specific data access absolutely  necessary - tieing it all together is still a challenge.

"specific data access" meaning what exactly? As said you can directly run sql queries etc against a query object. What else do you need

OK....   so that's where I am coming from...   and i still think a wrapper might be the way to  go.

A wrapper around what? How would that change your application architecture?

Thanks,
BigChimp

[Pascaluvr]

Big  Chimp.....   thank again.

starting at the bottom ...   the 'Wrapper' is some pas code for direct access to sqlite.  I guess I like the concept for 2 reasons =1) OOP aint my bag, 2) documentation for the Las components is skimpy.  I guess i would 'reinvent the wheel' to a certain extent, but i would feel  confident with my results.

I guess with many tables its always a concern - being sure that its the right table - the right data - is always a worry.

I am sure that multiple data sources would do the trick, but  maybe its just me, having faith in abstract components, especially in a multiple situation, is hard for me to handle.

Being an old procedural programmer - some changes are difficult.

[BigChimp]

starting at the bottom ...   the 'Wrapper' is some pas code for direct access to sqlite.  I guess I like the concept for 2 reasons =1) OOP aint my bag, 2) documentation for the Las components is skimpy.  I guess i would 'reinvent the wheel' to a certain extent, but i would feel  confident with my results.

Well, I can relate. However, I can't understand why you would want to use that direct access code to sqlite as you lose db compatibility... and I'd say it's too low level to be productive.
Why not use regular FPC sqldb units? See the link about database debugging in my first post (I think) that demonstrates its use.

Documentation at
http://www.freepascal.org/docs-html/fcl/sqldb/index.html

You can not only use sqlite with that, but also Firebird, PostgreSQL, MS SQL Server...

Another alternative is zeos, which apparently is quite good.

That said, if you want to use the sqlite "wrapper", well, I won't stop you

Edit: oops, missed the procedural<>OOP thing... even though you spelled it out. Well, ok, knock yourself out, but there are other low level db access units built into fpc...
see e.g. $(fpcdirectory)\packages\sqlite
the OOP sqldb code uses that to present the OOP interface.
Similar units for other dbs (interbase/firebird, etc)

[Pascaluvr]

Thanks Big  Chimp,

I do appreciate your responses.
Since I have no Delphi experience, No SQL experience, this really becomes a way for me to learn.   The components required to do some programming at the database level become  little overwhelming (for me).  So learning whats needed at a low level is a great way for me to learn and appreciate what the higher level components do for me.  If i understand the low-level stuff - the hi-level becomes easier to understand - rather than just accepting blindly that it works.. so dont worry about it.

I'll give a simple example:  when i first started using Laz I didnt use the form designer - i used Windows API calls to define my window(form) and controls.  It was after this I started to understand what Laz form design did for me.  I expect (hope) that as i use the lo=level sql access that i will understand more what the Laz DB components do for me - and i will start using them.

To further qualify ...   OOP is not in my level of expertise either - but once i understand the underlining code - i can use these components - but i get a mental block at using these blindly.

Happily, FPC/Laz accepts a mixture of OOP and procedural code = probably not pretty for another to read - but i am just writing as a hobby for me, not another.

Again, Big Chimp, thank you for your patience and assistance - it is getting me there.. slowly in my own way 

[BigChimp]

Ok, I understand. The only thing that was throwing me off was that you would be writing OOP code when interacting with the GUI anyway....

Well, good luck and have fun