Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-06

db components

7 messages · 6 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Rick Dawson

Has anyone started on db components yet? I have yet to get a working copy of the project yet so that I can really find out, so I thought I would ask.

What direction is it taking / would it take? I have been looking iodbc and unixodbc a bit, and have come across a few references about kde and gnome might be including iodbc, or a dirivative thereof, in the future. The iodbc, is, I believe, supposed to be source compatible with MS's odbc spec.

This is of prime importance to me, much more so than your debate over where to base your controls, in GTK or QT. My job is to do 'database development', which I do in Delphi. I would like, very much for my delphi code to continue on into the Linux environment.

Since this is my area of experience, I am willing to devote some of my time to this part of the project, though it would probably only be a couple of hours a week. I am slow, but I think I can contribute. Besides, I have several problems with Delphi's implementation of TTable and TQuery, such as they don't implement the 'recno' property for SQL databases like they should. That would have been a tremendous help in my current project.

Rick Dawson

**************************************************************************** not available in any store * Jerry U. "Rick" Dawson If you order now, * work:
You will get Ginsu Knives with your * home:
Custom Database Application *
****************************************************************************

Reply by email

d0hb0y
to Rick Dawson

Rick,

I would like to discuss Database interactions further if you decide to pursue this project. My job is primarily database application development as well, although since I work in Visual Basic I may have some interesting ideas to throw into the mix as well.

I would love to see myths like bound controls implemented correctly in my lifetime -- and M$ after 7 years of promising Bound Controls has failed to grasp how to do them correctly in a wan environment. Anyway I do not want to shoot this list server off onto a tangent, we could probably fill a whole other list server with database ideas. In fact, if anyone is interested in brainstorming some database interface ideas in lazarus, I'd be willing to set up a listserver here for that purpose.

== Ron

you wrote 34 lines
Has anyone started on db components yet? I have yet to get a working copy of the project yet so that I can really find out, so I thought I would ask. What direction is it taking / would it take? I have been looking iodbc and unixodbc a bit, and have come across a few references about kde and gnome might be including iodbc, or a dirivative thereof, in the future. The iodbc, is, I believe, supposed to be source compatible with MS's odbc spec. This is of prime importance to me, much more so than your debate over where to base your controls, in GTK or QT. My job is to do 'database development', which I do in Delphi. I would like, very much for my delphi code to continue on into the Linux environment. Since this is my area of experience, I am willing to devote some of my time to this part of the project, though it would probably only be a couple of hours a week. I am slow, but I think I can contribute. Besides, I have several problems with Delphi's implementation of TTable and TQuery, such as they don't implement the 'recno' property for SQL databases like they should. That would have been a tremendous help in my current project. Rick Dawson **************************************************************************** not available in any store * Jerry U. "Rick" Dawson If you order now, * work: You will get Ginsu Knives with your * home: Custom Database Application * **************************************************************************** _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Markus Goetz
to Rick Dawson: Has anyone started on db components yet? I have yet to get a working copy of the project…
Rick Dawson wrote
Has anyone started on db components yet? I have yet to get a working copy of the project yet so that I can really find out, so I thought I would ask.

OK, it seems that lazarus really has the potencial to be a great Delphi Clone, but as long as my lazarus doesn't work this means nothing :-(

What about first making a basic version run for everyone and then making the other stuff ?

Markus

PS : Qt is good, but since we only need Linux (Unix) GTK would be better.

My Name : Markus Goetz (aka guruz) My Mail Adress : My ICQ UIN : 23244271# My place on the web : http://guruz.tsx.org My favourite OS : Linux

Reply by email

Michael Van Canneyt
to Rick Dawson: Has anyone started on db components yet? I have yet to get a working copy of the project…
Rick Dawson wrote 12 lines
Has anyone started on db components yet? I have yet to get a working copy of the project yet so that I can really find out, so I thought I would ask. What direction is it taking / would it take? I have been looking iodbc and unixodbc a bit, and have come across a few references about kde and gnome might be including iodbc, or a dirivative thereof, in the future. The iodbc, is, I believe, supposed to be source compatible with MS's odbc spec. This is of prime importance to me, much more so than your debate over where to base your controls, in GTK or QT. My job is to do 'database development', which I do in Delphi. I would like, very much for my delphi code to continue on into the Linux environment.

I am writing TDataset and descendents, compatible to the Delphi ones. However, the TDAtaset stuff will not go in the Lazarus project, it will go in the underlying FCL components; for the simple reasons that
1) They are not GUI/Toolkit dependent.
2) Everyone should benefit from them, not just the lazarus people. So it will be part of the compiler suite.

I am quite busy with them, however I will not release anything until the code works.

At the moment, three descendents of TDataset will be created:
- TMySQLQuery, TMySQLTable (to handle MySQL based databases, as a test case)
- TRecordset (To directly handle records stored in a file) More can be added later (for instance TODBCDataset).

Show quoted text 7 lines
Since this is my area of experience, I am willing to devote some of my time to this part of the project, though it would probably only be a couple of hours a week. I am slow, but I think I can contribute. Besides, I have several problems with Delphi's implementation of TTable and TQuery, such as they don't implement the 'recno' property for SQL databases like they should. That would have been a tremendous help in my current project.

I am open to improvements of the TDelphi TDataset implementation. I Do think that compatibility is important. Exprience shows that users ask 2 things:
1) Cross-platform independence
2) Borland compatibility.

I intend to give them both as much as possible.

Concerning iodbc, i think a TDataset descendent needs to be written for it: TODBCDataset.

If we can manage to make generic 'TTAble' and 'TQuery' components, I will be happy, but it is not on my priority list. Experience has shown that usually one develops for one particular kind of database, so I think it is more useful to have descendent objects that work specifically on one kind of database; the advantage is a distinct speed gain.

But I have ideas about implementing generic TTable and TQuery components, and some kind of BDE replacement, for easy configuration.

You're welcome to contact me and discuss what we can do.

Michael.

Reply by email

Shane Miller

Just to keep me informed on every aspect of Lazarus, I wouldn't mind if you posted the discussion here, but simply put in the subject "Database discussion" or something for those not interested.

Shane

Earlier message 72 lines
-----Original Message----- From: d0hb0y To: Date: Monday, June 28, 1999 4:41 PM Subject: Re: [lazarus] db components >Rick, > >I would like to discuss Database interactions further if you decide to >pursue this project. My job is primarily database application development >as well, although since I work in Visual Basic I may have some interesting >ideas to throw into the mix as well. > >I would love to see myths like bound controls implemented correctly in my >lifetime -- and M$ after 7 years of promising Bound Controls has failed to >grasp how to do them correctly in a wan environment. Anyway I do not want >to shoot this list server off onto a tangent, we could probably fill a >whole other list server with database ideas. In fact, if anyone is >interested in brainstorming some database interface ideas in lazarus, I'd >be willing to set up a listserver here for that purpose. > >== Ron > >At 08:43 AM 6/28/99 -0500, you wrote: >>Has anyone started on db components yet? I have yet to get a working copy >>of the project yet so that I can really find out, so I thought I would ask. >> >>What direction is it taking / would it take? I have been looking iodbc and >>unixodbc a bit, and have come across a few references about kde and gnome >>might be including iodbc, or a dirivative thereof, in the future. The >>iodbc, is, I believe, supposed to be source compatible with MS's odbc spec. >> >>This is of prime importance to me, much more so than your debate over where >>to base your controls, in GTK or QT. My job is to do 'database >>development', which I do in Delphi. I would like, very much for my delphi >>code to continue on into the Linux environment. >> >>Since this is my area of experience, I am willing to devote some of my time >>to this part of the project, though it would probably only be a couple of >>hours a week. I am slow, but I think I can contribute. Besides, I have >>several problems with Delphi's implementation of TTable and TQuery, such as >>they don't implement the 'recno' property for SQL databases like they >>should. That would have been a tremendous help in my current project. >> >>Rick Dawson >> >> >>************************************************************************** ** >> not available in any store * Jerry U. "Rick" Dawson >> If you order now, * work: >> You will get Ginsu Knives with your * home: >> Custom Database Application * >>************************************************************************** ** >> >>_________________________________________________________________ >> To unsubscribe: mail with >> "unsubscribe" as the Subject >> archives at http://www.miraclec.com/list_archives/lazarus > >_________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.miraclec.com/list_archives/lazarus >

Reply by email

Michael Van Canneyt
to Lothian, Nicholas ETSA: (Ron, I tried to send this direct to you, but it bounced...) I, too would be very…
Nicholas wrote 16 lines
(Ron, I tried to send this direct to you, but it bounced...) I, too would be very interested in this discussion. I realize we are probably getting a bit ahead of ourselves - discussing DBControls when the normal ones aren't all working, but I think it would be a fruitful discussion to have. I've worked for nearly two years in a Delphi/Oracle environment, and I believe that the speed of development of client side database application is the greatest strength of Delphi, and one I would like to see Lazarus duplicate (or surpass). I can only offer a few hours a week on programming at the moment, but I am willing to have a go. Anyway, if you do decide to set up a list for DB/Laz discussion, please add me or forward me joining information.

I beg you: the DB components should not be part of lazarus, but should go in the underlying FCL - DB access is GUI independent. People writing text interfaces or command-line utilities also will want to use it.

That is why I am doing the TDataset implementation in the FCL, not in lazarus. Lazarus can use it of course, but it shouldn't be part of it. The lazarus team should do the database aware GUI elements like TDBEdit, TDBGrid, TDBMemo etc, but the Tdataset itself should not be part of it.

I think it is a good idea setting up a list about DB components, but I will finish the basic implementation first. That can then be expanded to our wishes/likes.

If someone sets up a mailing list, please inscribe me !

Michael.

Reply by email

Lothian, Nicholas ETSA

(Ron, I tried to send this direct to you, but it bounced...)

I, too would be very interested in this discussion. I realize we are probably getting a bit ahead of ourselves - discussing DBControls when the normal ones aren't all working, but I think it would be a fruitful discussion to have.

I've worked for nearly two years in a Delphi/Oracle environment, and I believe that the speed of development of client side database application is the greatest strength of Delphi, and one I would like to see Lazarus duplicate (or surpass). I can only offer a few hours a week on programming at the moment, but I am willing to have a go.

Anyway, if you do decide to set up a list for DB/Laz discussion, please add me or forward me joining information.

Thanks.

Nick Lothain

Show quoted text 21 lines
---------- From: Sent: Tuesday, 29 June 1999 9:03 To: Subject: Re: [lazarus] db components Rick, I would like to discuss Database interactions further if you decide to pursue this project. My job is primarily database application development as well, although since I work in Visual Basic I may have some interesting ideas to throw into the mix as well. I would love to see myths like bound controls implemented correctly in my lifetime -- and M$ after 7 years of promising Bound Controls has failed to grasp how to do them correctly in a wan environment. Anyway I do not want to shoot this list server off onto a tangent, we could probably fill a whole other list server with database ideas. In fact, if anyone is interested in brainstorming some database interface ideas in lazarus, I'd be willing to set up a listserver here for that purpose.

Reply by email