Hi,
this may not be entirely on-topic to this list, apologies for that; (But since I am (currently) using Lazarus 0.9.28.2 r22279 FPC 2.2.4, (and planning to upgrade to latest stable 0.9.30/2.4.something /windows/ installer distribution), the offtopic is somehow diminished)

I looked up http://wiki.lazarus.freepascal.org/ODBCConn, http://wiki.lazarus.freepascal.org/Databases, read http://wiki.lazarus.freepascal.org/Lazarus_DB_Faq so far, I recreated and run successfully the example (the one with dbgrid) from http://www.lazarus.freepascal.org/index.php?topic=3329.0, on an existing database; (yes the UsePrimaryKeyAsKey is unsupported in ODBC, TSQLQuery has to have that set as false otherwise ODBC driver throws errors)

As at some point I will have to use other (say Firebird) access without using visual components, I am trying to explore as much as possible with RAD...

I never used the OOP approach to database programming before, hence I feel like I am trying to do a second step before doing the first...

Where can I find some absolute beginners guide to
OOP database (well maybe not /that/ absolute but answering questions like - what's the idea behind the splitting the database access into Connection, Query, Transaction and DataSource? Or some actually /helpful/ examples of reading, writing, updating, deleting etc. data using this paradigm)
I mean I can see what it does but I feel like I'm not entirely in control of what happens at which stage... and that's disturbing :) What I know so far is like showing a 'Hello World' program to a beginner, and expecting he'll be absolutely _stunned_ at the beauty and simplicity of it, but the beginner goes "oh what the heck, this just spits 'Hello World' on your screen, I don't get it what's the whole fuss about...? And what /exactly/ is this supposed to demonstrate to me?"

(I'm slightly more familiar with microcontroller programming, in case somebody thinks I'm totally ignorant...)

(

Now for more on-topic:
I have a testing app using one of the examples as the base of it, the one with dbgrid:

procedure TForm1.Button1Click(Sender: TObject);
begin
  if Label1.Caption = 'ODBC Disconnected' then
    if OpenDialog1.Execute then
      begin
        ODBCConnection1.Params.Add('DBQ='+OpenDialog1.FileName);
       // ODBCConnection1.Open;
        SQLQuery1.SQL.Clear;
        SQLQuery1.SQL.Add('SELECT * FROM MyTable');
        SQLQuery1.Open;  // SIGSEGV when calling a second time
        exit;
      end;
  if Label1.Caption = 'ODBC Connected' then
    begin
      SQLQuery1.Close;
      ODBCConnection1.Close;
      exit;
    end;
end;

So I can actually point to the MDB file I want to look into, but then, when I close it (using the SQLQuery.Close part of the above), and then try to open it again (using the first part again) I get a 'External: SIGSEGV' at the SQLQuery1.Open; call.
(This happens regardless of whether I have the SQLQuery.Close call for the closing case or not)

?

)

(Hope I did not bore everybody yet...)
Thanks in advance,
Lukasz

Maybe we should stop you right there, and teach you the "correct" OOP way of doing database programming. :) No GUI unit should contain code as listed above... Database connections, Query components, embedded SQL, manual transaction handling etc. Yuck! Instead, use a OPF (Object Persistent Framework) that hides all that ugliness and let you only work with Business/Data Objects instead - the true OOP way.

For a broad overview of tiOPF (a free OPF framework for Delphi and Free Pascal, and that works with VCL, LCL and fpGUI), see the following URL.

http://tiopf.sourceforge.net/Doc/Concepts/index.shtml

For example, changing your code above to something as shown below:

var
  oList: TMyTableList;
begin
  oList := TMyTableList.Create;
  oList.Load;
  { now you have list of TMyTableItem objects to do as you please }

Now say we want to load that list, and display that list of objects in a grid (named StringGrid1).

var
  oList: TMyTableList;
  FModelMediator: TtiModelMediator;
...
begin
  oList := TMyTableList.Create;
  oList.Load;
  FModelMeditor := TtiModelMediator.Create;
  FModelMediator.AddComposite('ID;Type;Name', StringGrid1);
  FModelMediator.Subject := oList;
  FModelMediator.Active := True;
end;

If you now Add or Remove or Change any data inside oList, the StringGrid1 will automatically be updated for you.

NOTE:
The above code is done manually to show you the details of how it works. You can also use the "RAD" style of development, by dropping a TtiModelMediator component on a form and hooking up the properties via the Object Inspector.

Now, saving the list back to the database is as simple as...

  oList.Save;

Transaction handling, rollback on error etc are all handled for you.

OPF frameworks like tiOPF really make using databases easy - including creating UI for your data. tiOPF also works with multiple database (Firebird, MySQL, Oracle, MDB, etc) and multiple database connection components (SqlDB, FBLib, dbExpress, Zeos, UIB, OIB etc). So you are definitely NOT locked into some specific vendor or suite of components. And as you have seen from the example above, you application code doesn't need to change at all, even if you switch from Firebird to PostgreSQL, or from SqlDB to UIB components. It's all simply controlled by a single compiler define.

http://www.tiopf.com

See also the Lazarus wiki page:

http://wiki.lazarus.freepascal.org/tiOPF

tiOPF has been used in production environments for well over a decade and has just under 2000 unit tests which run hourly to make sure it stays rock solid.

Regards,
- Graeme -

I knew I could count on Graeme for an answer (and a plug ;)

On 20/09/2011 14:42, Graeme Geldenhuys wrote:
[snip]

Maybe we should stop you right there, and teach you the "correct" OOP way of doing database programming. :) No GUI unit should contain code as listed above...

That was just an example. the 'hello world' of databases :P and only included cause I got an SIGSEGV in it...

Thing is - I may not need to know how the sewers work, that they need to be laid with some sort of descent ;) or that you should not use thin walled plastic pipes 15 meters underground ;) but it helps to know where the manhole covers are in case it rains, so your car won't get washed away when you build your garage over one...

Thanks. Will have a read.

For example, changing your code above to something as shown below:

[snip code]
Thing is, this is yet another abstraction layer... see my remark about sewers. My understanding of abstractions so far tries to embrace simple OOP and inheritance, I don't even understand Interfaces yet...

Yeah that's cool, but yeah, the target when it's prime-time will be non-visual, at least in one end...

Never been happier, still -see my remark about sewers. (Or LWN article about abstraction trap)

Should have added (PLUG) into topic ;)

Regards, - Graeme -

Thanks for this,
many hours of reading, here I come.

Lukasz

I don't think that you can help anyone on this list with answers to questions which aren't posed:

Q: "How do I solve this problem in method 'A'"?
A: "Well, use method 'B', it's better."

First of all it is not the answer to the question. And secondly in this case it does not solve the problem, because the underlying database-problem will also occur when this is all rewritten to use a proper OPF.

I know that you do not want to advertise tiOPF alone, but also want to teach people something. But this time the answer is completely unrelated. And if you really couldn't it could have been much shorter. Like: 'Hmm... I can not help you with your problem, but maybe you could take a look at a better design of your code and split your GUI-code from the actual work. Google for ....'

Joost

IIRC, this has been solved in fpc 2.4.4.

Joost

Lukasz Sokol wrote

this may not be entirely on-topic to this list, apologies for that;

Hmm... I can not help you with your problem, but maybe you could take a look at a better design of your code and split your GUI-code from the actual work. Google for ....

[Joost never gave the answer the the Google search. ;-). Happy Joost?]

Regards,
- Graeme -

http://www.google.co.uk/search?q=lmgtfy&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

<grin>

Lukasz Sokol wrote

Thing is - I may not need to know how the sewers work, that they need to be laid with some sort of descent ;) or that you should not use

Then buy a old Delphi 7 (where you still get printed manuals in the box) and read them from cover to cover.

Regarding OOP in general and what it tries to accomplish.... Google it, there are too many to list. Embarcadero also has a Delphi OOP forum dedicated to OOP questions, so it might be worth visiting that too.

simple OOP and inheritance, I don't even understand Interfaces yet...

The tiOPF framework doesn't use Interfaces, so you are OK there. ;-)

Yeah that's cool, but yeah, the target when it's prime-time will be non-visual, at least in one end...

tiOPF doesn't force GUI type applications. I have developed GUI and CGI apps using tiOPF. The OOP design (promoted by tiOPF) clearly split my code into logical layers: business objects and rules, persistence backend, UI (web or desktop).

Never been happier, still -see my remark about sewers. (Or LWN article about abstraction trap)

Common sense and basic OOP design skills work wonders too. Anybody can f*ck-up any OOP (or otherwise) code - give enough [or the lack their off] skills.

Regards,
- Graeme -

OK, one more reason to upgrade... :)

But then, after that it is enough that I ODBCConnection1.Close just, yes ?

Lukasz

I read one once (don't remember the title but it was the one that had 700+ pages and a detective story in some chapters - i think it's the one some people refer to as D7 Bible...). The database related chapter was by far the most booooring :P so I did not pay much attention to it, I admit. (but then I was <18 at the time, and now slightly >30 ;) )

Regarding OOP in general and what it tries to accomplish.... Google it, there are too many to list. Embarcadero also has a Delphi OOP forum dedicated to OOP questions, so it might be worth visiting that too.

<grin> lmgtfy.com :)

That's also what I have in mind, so the logic can exist without gui. And it will, in the future.

But at this /really/ simple stage I am at the moment, I am /only/ doing things like the code I included before, to trigger some events manually to be able to observe the flow (e.g. catch it in breakpoints) to try to understand what happens where.
(This is nowhere near RAD, I know... but that's what you get when learning on the job, meh)

Yeah. Right.
(Back to RTFM then ;)

Regards, - Graeme -

Thanks,
Lukasz

Lukasz Sokol wrote

On 20/09/2011 16:11, Joost van der Sluis wrote:

[...]

For the record - it works in Lazarus 0.9.30 r29749 FPC 2.4.2 i386-win32-win32/win64, and it's enough to ODBCConnection1.Close ;)

Lukasz

I think it is time on Object Persistence Framework gained more traction in the FPC/Lazarus environment.

After a while thinking in terms of SQL, FieldByName etc becomes mentally exhausting. There is a huge impedance mismatch here.

Hi Frank,

yeah why not, I'm not saying I won't look at that... see my parallel to sewer system thou ;)
(I don't need to know how pipes are made or how deep they are buried, but need to know where the manholes and sink holes are in case it rains and they be about to burst up...)

(By the way : sorry for not quoting, but your post came totally mangled on quoting Graeme (my mailer
displayed your reply on the same level of quoting as what Graeme wrote).

K-R
Lukasz