Hi all,

I'm busy implementing TBufDataset.Locate and friends. I had the idea to overload Locate like this:

function Locate(const keyfields: string; const keyvalues: Variant;
  options: TLocateOptions; LocateNext : boolean ) : boolean;

So that it's possible to doe a 'locatenext'

But I saw that sqlite simply has a 'locatenext' function. But it is also possible to add a TLocateOption...

I'm thinking about implementing this (abstract) at the TDataset level. What option should I choose and what do you guys think the idea?

I think .Filter in combination with .FindFirst/Prior/Next/Last is just as powerful, so a LocateNext should not be needed. Does Locate guarantee finding the first record that matches ?

Micha

It should.

Personally, I always use filter for such things.

Michael.

Hi All,

I'm new here - variously playing with Lazarus and mseide&msegui. I posted the :

and got the following from Martin...

This problem lies probably in the underlying TSQLQuery. Could you discuss it with Jost van der Sluis at FPC-Devel mailing list?

I've looked in the 2.0.2 source, 2.0.3 snapshot source, 2.1.x snapshot source and don't see an obvious reason why character and date fields would work differently from decimal although I noticed comments somewhere last week about the "new" decimal field in MySQL version 5.0.

The function MySQLDataType, in fcl/db/sqldb/mysql/mysqlconn.inc refers to FIELD_TYPE_DECIMAL in one of the case clauses. Perhaps version 5.0 changed this value?

On another matter, are there any plans to implement a datasource property on TMySQLQuery for resolving parameters? This is a very powerful facility. I think I know a workaround, but I'd prefer not to use it.

Doug

Probably that is used.

The function MySQLDataType, in fcl/db/sqldb/mysql/mysqlconn.inc refers to FIELD_TYPE_DECIMAL in one of the case clauses. Perhaps version 5.0 changed this value?

No. It did introduce a new type "MYSQL_TYPE_NEWDECIMAL"

I added support for this new fieldtype.

On another matter, are there any plans to implement a datasource property on TMySQLQuery for resolving parameters? This is a very powerful facility. I think I know a workaround, but I'd prefer not to use it.

It is implemented for SQLDB since last week, but for MySQL it doesn't work yet: the parameters are ignored. (because MySQL has no native parameter support) It does work for firebird and postgres. It should be easy to add, however, to mysql. All that needs to be done is to replace the parameter names with the actual current values.

Michael.

Not really. Sometimes I use a locate to find a record in a dataset. I don't want to limit the records in that dataset with a filter.

Marc

If you don't want to limit, then set .Filtered := false; and use
FindFirst etc.

Micha

There is no need to pass again keyfields, keyvalues and options parameters to locate next match. What to do if they are not the same as for first locate?
IMO sqlite aproach is better.

I'm thinking about implementing this (abstract) at the TDataset level. What option should I choose and what do you guys think the idea?

I think a LocateNext function would be fine.

Alex

wich won't work with current sqldb, since filtering there simply adds a 'where' part to the query.
An which is much slower then locate and locatenext.

Isn't the mean reason why you and Michael aren't using locate, that locatenext is missing?

I planned to give locatenext exactly the same parameters as locate itself. So you have to pass the same parameters again, but it adds some flexibility. For example if you're on a 'random' record, and want to locate the next one. Then you won't need to do a 'locate' first, but can do a locatenext immediately.

Joost

Then i suggest you to name that function LocateRest. Both functions are useful.

Alex

I definitely use locate.

But if I would need a 'LocateNext' kind of functionality, I would use a filter.

Michael.

Just one information. I based the LocateNext implemetation of TCustomSqliteDataset in the found at FIBL which was the only TDataset that had it implemented.
Here is the FIBL approach:

function Locate(const KeyFields: String; const KeyValues: Variant;
      Options: TLocateOptions): Boolean;
function LocateNext(const KeyFields: String; const KeyValues: Variant;
      Options: TLocateOptions): Boolean; // Sister function to Locate

Luiz

Same story for TDbf :-).

Isn't the mean reason why you and Michael aren't using locate, that locatenext is missing?

Oh, I am using Locate. I'm just talking from the general TDataSet POV.

That said, LocateNext may be useful, but I would rather add a flag to Locate; a TLocateNagivation (lnFirst, lnPrior, lnNext, lnLast), with the default being lnFirst, thus compatible. It's a bit more flexible.

OTOH, is it really impossible to do it the "right" way, implementing the filter more efficiently, in sqldb ?

Adding redundant ways to do the same thing is not ideal IMHO.

Micha