Sign in Join

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

Mailing lists / fpc-devel / 2004-07

dbase compile and install on linux

9 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Vincent Snijders

Hi,

Attached patch fixes the installation problems some people had with the dbase units. The install program refused to install the units twice.

Attached patch contains a patch for the Makefile.fpc, a patch for fpcmake to correctly interprete units_i386 as part of the target section and a patch for the resulting Makefile, which you can make yourself too with the patched fpcmake.

Regards,
Vincent Snijders.

Reply by email

Unknown author
to Vincent Snijders
Vincent Snijders wrote 5 lines
Hi, Attached patch fixes the installation problems some people had with the dbase units. The install program refused to install the units twice. Attached patch contains a patch for the Makefile.fpc, a patch for fpcmake to correctly interprete units_i386 as part of the target section and a patch for the resulting Makefile, which you can make yourself too with the patched fpcmake.

Applied, thanks.

Michael.

Reply by email

Joost van der Sluis
to Unknown author

Hi,

I want to discuss something before i make all sort of changes...

Now TDataset uses a buffer of default 10 records. If you go to the 11th record, the first record is removed from memory. If you go to the first record, all buffers are cleared, and then they are read again from the first record. All this is done by tdataset.

This works good for tdbf but it gives some problems with SQL-based descendants, especially those for DB-servers that don't support bidirectional cursors. (like Firebird)

If you fetch records from a table using a sql-query, you'll get all the records, beginning with the first one, then the second one etcetera. But you can't go back. If you've just fetched the 1000 record, and you need record 999, you have to start all over again, beginning with record number one.

This gives some problems if you're buffer is holding the records 1000-1010. If you scroll back from record 999 to 1 the use of bandwith will be huge.

The solution is to hold all records into memory once they are fetched. At first sight you will say that that cost an huge amount of memory, but i doesn't. Because if you used the SQL server right, you only ask for the records you need by using a 'where' statement.

I see three solutions:

1: Make the tdataset descendents so that they do the fetch from the first record if you want the prior record. Which is the worst solution, I hope you all agree with that. (It's the current solution, though. Only it don't work)
2: Leave the creation and maintenance of the buffer to the tdataset descendants, in stead of tdataset itself. So that every tdataset descendent can use it's own buffer-system. (This solution is the one i was trying, and it can be done. Some small changes to tdbf are needed, though. And all other descendents have to been looked at too.) 3: Add a property to TDataset, which changes the behaviour of the buffers, so that they are 'infinitive'. All fetched records are kept in memory. The descendents that need this can set this property in their create-functions. Delphi has something like this, if you set the buffercount to -1.

I think i'm going to try to implement option three. But what do you all think about this issue?

Further i've fixed a bug that made it impossible to show an integer field in a tdbedit.

fields.inc: tlongintfield.gettext now uses getvalue so that the typecasting is used correctly.

diff is attached.

Joost van der Sluis.

Reply by email

Joost van der Sluis
to Joost van der Sluis

Hi all,

could someone rename all units in fcl/db/dbase to lowercase and make the changes to the makefile and such?

Now the tdbf lazarus-components won't compile, because it uses 'DBF' in stead of 'Dbf'. I can change that, but if someone else wants to use the dbf-unit he has to known that he has to use 'Dbf'

Further the debugger doesn't work with the filenames which are used now in the CVS.

I know that tdbf is not only a fpc-package, but the filenames as they are now are highly irritative/buggy.

Joost van der Sluis.

Reply by email

Unknown author
to Joost van der Sluis: I want to discuss something before i make all sort of changes... Now TDataset uses a…
Joost van der Sluis wrote 34 lines
Hi, I want to discuss something before i make all sort of changes... Now TDataset uses a buffer of default 10 records. If you go to the 11th record, the first record is removed from memory. If you go to the first record, all buffers are cleared, and then they are read again from the first record. All this is done by tdataset. This works good for tdbf but it gives some problems with SQL-based descendants, especially those for DB-servers that don't support bidirectional cursors. (like Firebird) If you fetch records from a table using a sql-query, you'll get all the records, beginning with the first one, then the second one etcetera. But you can't go back. If you've just fetched the 1000 record, and you need record 999, you have to start all over again, beginning with record number one. This gives some problems if you're buffer is holding the records 1000-1010. If you scroll back from record 999 to 1 the use of bandwith will be huge. The solution is to hold all records into memory once they are fetched. At first sight you will say that that cost an huge amount of memory, but i doesn't. Because if you used the SQL server right, you only ask for the records you need by using a 'where' statement. I see three solutions: 1: Make the tdataset descendents so that they do the fetch from the first record if you want the prior record. Which is the worst solution, I hope you all agree with that. (It's the current solution, though. Only it don't work)

The TDataset descendent should handle it optimally. IBX fetches and stores results 'as you go', using an incremental scheme. If you go back, it just returns in the data already in memory.

Show quoted text 5 lines
2: Leave the creation and maintenance of the buffer to the tdataset descendants, in stead of tdataset itself. So that every tdataset descendent can use it's own buffer-system. (This solution is the one i was trying, and it can be done. Some small changes to tdbf are needed, though. And all other descendents have to been looked at too.)

This is not possible, as grids needs to handle more than just the current buffer. It needs a consistent interface. The current method ensures this. There is also compatibility to be considered.

Show quoted text 5 lines
3: Add a property to TDataset, which changes the behaviour of the buffers, so that they are 'infinitive'. All fetched records are kept in memory. The descendents that need this can set this property in their create-functions. Delphi has something like this, if you set the buffercount to -1.

Delphi does this only for TClientDataset, never for an ordinary dataset. TClientDataset is something we should have, but then we need lots more functionality as well.

I think i'm going to try to implement option three. But what do you all think about this issue?

I think the best thing is a hybrid approach between TDataset and what IBX does. I suggest you make a TDataset descendent which does all the buffer handling as you wish (Call it e.g. TBufDataset).

To do this, some methods/fields of TDataset will need changing: methods/fields should be made protected/virtual etc. We can discuss these changes in TDataset methods as needed, I'll be glad to assist.

This approach has 2 advantages:
- People who want to use the new TBufDataset functionality can do so by descending from this component instead of TDataset.
- At the same time, the old TDataset methods should be kept for compatbility with existing components...

Show quoted text 8 lines
Further i've fixed a bug that made it impossible to show an integer field in a tdbedit. fields.inc: tlongintfield.gettext now uses getvalue so that the typecasting is used correctly. diff is attached.

Applied, thank you.

Michael.

Reply by email

Unknown author
to Joost van der Sluis: could someone rename all units in fcl/db/dbase to lowercase and make the changes to the…
Joost van der Sluis wrote 8 lines
Hi all, could someone rename all units in fcl/db/dbase to lowercase and make the changes to the makefile and such? Now the tdbf lazarus-components won't compile, because it uses 'DBF' in stead of 'Dbf'. I can change that, but if someone else wants to use the dbf-unit he has to known that he has to use 'Dbf'

I have already fixed the lazarus registration units just need to send them to someone of the lazarus group. Lazarus will insert the filename correctly when you add a component.

Further the debugger doesn't work with the filenames which are used now in the CVS.

Why not ?

I know that tdbf is not only a fpc-package, but the filenames as they are now are highly irritative/buggy.

I am reluctant to change the case, because TDBF is not a fpc package, and changing the filenames will break compatibility with Kylix (also supported by TDBF). Furthermore, it means changing all filenames each time I import the component from TDBF cvs...

Maybe Micha Nelissen can give some opinions/ideas ? If he gives the go-go, I'll change it in FCL CVS...

Michael.

Reply by email

Joost van der Sluis
to Unknown author
I have already fixed the lazarus registration units just need to send them to someone of the lazarus group. Lazarus will insert the filename correctly when you add a component.

I did that here also. But what is someone put is 'uses dbf' by himself? He will never know why this isn't working, unless he knows how fpc handles lowercase/uppercase unit file names.

> Further the debugger doesn't work with the filenames which are used now in > the CVS. Why not ?

That's a good question. But try it, place a breakpoint in dbf.pas and see how the breakpoint is ignored. But it works when you trace into a method which is implemented in dbf.

Lazarus can't place the breakpoint: (The file does exist) TDebugManager.BreakpointAdded A /home/test/fpc/fpc/fcl/db/dbase/Dbf.pas 809
[Debugger] Log output: &"No source file named Dbf.pas.\n"

Show quoted text 5 lines
> I know that tdbf is not only a fpc-package, but the filenames as they are > now are highly irritative/buggy. Maybe Micha Nelissen can give some opinions/ideas ? If he gives the go-go, I'll change it in FCL CVS...

On IRC he said i should talk to you. ;)

Joost van der Sluis.

Reply by email

Unknown author
to Joost van der Sluis
Joost van der Sluis wrote 28 lines
> I have already fixed the lazarus registration units just > need to send them to someone of the lazarus group. Lazarus will insert the > filename correctly when you add a component. I did that here also. But what is someone put is 'uses dbf' by himself? He will never know why this isn't working, unless he knows how fpc handles lowercase/uppercase unit file names. > > Further the debugger doesn't work with the filenames which are used now in > > the CVS. > Why not ? That's a good question. But try it, place a breakpoint in dbf.pas and see how the breakpoint is ignored. But it works when you trace into a method which is implemented in dbf. Lazarus can't place the breakpoint: (The file does exist) TDebugManager.BreakpointAdded A /home/test/fpc/fpc/fcl/db/dbase/Dbf.pas 809 [Debugger] Log output: &"No source file named Dbf.pas.\n" > > I know that tdbf is not only a fpc-package, but the filenames as they are > > now are highly irritative/buggy. > > Maybe Micha Nelissen can give some opinions/ideas ? If he gives the go-go, > I'll change it in FCL CVS... On IRC he said i should talk to you. ;)

OK. I'll lowercase all filenames in the FCL, I have no problem with that. It's how it is by default for all other units.
Expect a big update from CVS in that case...

Though I don't like the discrepancy with the 'official' TDBF...

Michael.

Reply by email

Joost van der Sluis
to Joost van der Sluis: I want to discuss something before i make all sort of changes... Now TDataset uses a…

Hi all,

i have some fixes/additions:

- With the patch in the attached dataset.inc.diff(2) tdataset now posts changes before scrolling to another record (ie first, next etc.) like Delphi does.

- In interbase.pp.diff(2) the ExecuteDirect method is added to TIBDatabase

And further i've implemented an BufferAllRecords property for TDataset like i suggested earlier. I don't know if you guys like this solution, but have a works perfect with
interbase (tibquery doesn't work properly without it) but also with tDbf.

If BufferAllRecords is set to true, all fetched records will be kept in memory. For tibquery this is the default.
(patch is in db.pp.diff, interbase.pp.diff, dataset.inc.diff)

Joost van der Sluis.

(reminder:)

Show quoted text 8 lines
3: Add a property to TDataset, which changes the behaviour of the buffers, so that they are 'infinitive'. All fetched records are kept in memory. The descendents that need this can set this property in their create-functions. Delphi has something like this, if you set the buffercount to -1. I think i'm going to try to implement option three. But what do you all think about this issue?

Reply by email