Board index » delphi » TIBDataSet.Locate, set current record

TIBDataSet.Locate, set current record

Hi!

Is there a way, to set the current record in a TIBDataSet to match a
primary search without using "Locate"?
TIBDataSet.Locate would do it, but I learnt: it doesn't use index, hence
it takes too long.

My goal is as follows:

I have a DBGrid wich displays the dataset (as result of an arbitrary
select statement).
Then I have a non-data-aware component (and it should stay
non-data-aware) to enter values.
If the button is pressed, the dataset should be updated.

Up to now I used TIBDataSet.Locate to scan for the ID, called
TIBDataSet.Edit, refreshed all fields, and called Post on the dataset.
Works fine with small datasets or subsets.

Now, Locate doesn't work for me (no index-search).
What then is the UpdateSQL-property in TIBDataSet for? Is it just for
data-aware entry?
Is the only way to set the current record by visually selecting it in
the grid (besides "locate", "first", "last" and so on)?
Can I call the Update-SQL method in TIBDataSet myself? Or is it
component driven only?

If I used a separate TIBSQL to update values, how do I tell TIBDataSet
to refresh one particular record?
Can I call the Refresh-method myself?

Any comments on this basic problems are veeeeery appreciated.
I fear, I completely misunderstand some things here.

Regards, Boris

 

Re:TIBDataSet.Locate, set current record


I'm longing for an answer to this question, too

Regards,

Peter

Re:TIBDataSet.Locate, set current record


Quote
Boris Schlszler wrote:

> Is there a way, to set the current record in a TIBDataSet to match a
> primary search without using "Locate"?

        Not without incurring as much overhead as Locate would.  IBX datasets
don't (presently) use any kind of circular buffering.  You always have,
at a minimum, the first record and every record up to the current record
in memory.

        This corresponds rather closely with how fetching in InterBase works.
You can't fetch bidirectionally or jump to the middle of a SELECTion.
To "go to the middle" you'd have to write a new query and execute that.

Quote
> TIBDataSet.Locate would do it, but I learnt: it doesn't use index, hence
> it takes too long.

        In this case, your dataset is too large.  In general, I consider it a
bad practice to present the user with more than a couple hundred records
in a list.  It's too much to scroll through.  When your result sets get
this big, you need to give the user tools to reduce the size of the
result set.  For example, instead of showing the user all payroll
records in a week, I give them a screen with tabs for each day of the
week.  It makes it much easier to find the record they're searching for.

Quote
> What then is the UpdateSQL-property in TIBDataSet for? Is it just for
> data-aware entry?

        UpdateSQL is used when you call Post after editing the dataset.  In
general, it's most useful for data-aware controls, but it would also be
used if you called Edit and then Post in code.

Quote
> Is the only way to set the current record by visually selecting it in
> the grid (besides "locate", "first", "last" and so on)?

        I'm not sure I understand your question.  The only way to move the
cursor is to move the cursor.

Quote
> Can I call the Update-SQL method in TIBDataSet myself?

        Don't fool with this.  The internal update query is protected for a
reason.

Quote
> If I used a separate TIBSQL to update values, how do I tell TIBDataSet
> to refresh one particular record?
> Can I call the Refresh-method myself?

        Yes, Refresh will refresh the current record only in IBX.

        HTH,

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

Re:TIBDataSet.Locate, set current record


"Craig Stuntz (TeamB)" schrieb:

Quote
> > TIBDataSet.Locate would do it, but I learnt: it doesn't use index, hence
> > it takes too long.

>         In this case, your dataset is too large.  In general, I consider it a
> bad practice to present the user with more than a couple hundred records
> in a list.  It's too much to scroll through.

You're right.
Problem is: I want grant the possibility to the user, to enter an arbitrary
select statement.
Maybe he just won't scroll through it.
Maybe he just ignores it.
But it should be there.

Quote
> > Is the only way to set the current record by visually selecting it in
> > the grid (besides "locate", "first", "last" and so on)?

>         I'm not sure I understand your question.  The only way to move the
> cursor is to move the cursor.

OK: I want to move the cursor to the record with ID=56 ("ID" is primary index).
How could I tell TIBDataSet?
If I look at the SQL-Statement in TIBDataSet, it should also be possible, to
"move" the cursor to a record, which isn't even in the dataset.
All the SQL-statements refer to a particular record via a primary index,
independently from what is exposed to the outer world with the initial SELECT.
There should be a way to set the Update/Refresh-parameters via
TIBDataSet-methods.

Quote
> > If I used a separate TIBSQL to update values, how do I tell TIBDataSet
> > to refresh one particular record?
> > Can I call the Refresh-method myself?

>         Yes, Refresh will refresh the current record only in IBX.

How do I refresh the record with ID=56 ("ID" is primary index)?
Problem is: DBGrid is displayed via datasource of TIBDataSet.
TIBSQL updates the data. How to tell TIBDataSet to refresh the updated record?

Re:TIBDataSet.Locate, set current record


Quote
Boris Schlszler wrote:

> You're right.
> Problem is: I want grant the possibility to the user, to enter an arbitrary
> select statement.

        You're a brave man.  Or you *really* trust your users.  Or both...

Quote
> Maybe he just won't scroll through it.
> Maybe he just ignores it.
> But it should be there.

        So don't just worry about large result sets.  If you're allowing the
users to enter arbitrary SELECTs, they can easily enter a query which
will essentially lock up their connection.  I wouldn't ever allow people
to do this.  

        If you do allow it, I would re-implement Locate so that it gives up
after a certain amount of searching.

Quote
> > > Is the only way to set the current record by visually selecting it in
> > > the grid (besides "locate", "first", "last" and so on)?

> >         I'm not sure I understand your question.  The only way to move the
> > cursor is to move the cursor.

> OK: I want to move the cursor to the record with ID=56 ("ID" is primary index).
> How could I tell TIBDataSet?

        Use Locate.  There is only one cursor for a dataset.

Quote
> If I look at the SQL-Statement in TIBDataSet, it should also be possible, to
> "move" the cursor to a record, which isn't even in the dataset.

        It shouldn't be possible.  The TIBDataset class is designed to
encapsulate an SQL result set.  While you could, with some hacking,
persuade the statements used to query the DB for information not in the
SelectSQL result set, this would be violating the design and intended
purpose of TIBDataset.  If you want something outside of the SelectSQL
result set, you need to change the SQL, param values, or use a different
dataset.

Quote
> All the SQL-statements refer to a particular record via a primary index,
> independently from what is exposed to the outer world with the initial SELECT.
> There should be a way to set the Update/Refresh-parameters via
> TIBDataSet-methods.

        No, there shouldn't, IMHO.  Don't think of TIBDataset as a group of
unrelated statements.  Rather, think of it as class which includes
properties and methods for operations on a *single* set of records.

Quote
> How do I refresh the record with ID=56 ("ID" is primary index)?

        You Locate there and call Refresh.

        HTH,

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

Re:TIBDataSet.Locate, set current record


Quote
> Is there a way, to set the current record in a TIBDataSet to match a
> primary search without using "Locate"?
> TIBDataSet.Locate would do it, but I learnt: it doesn't use index, hence
> it takes too long.

What part about my earlier post didn't you understand? I thought I gave a
very clear and detailed explanation of this.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Re:TIBDataSet.Locate, set current record


Quote
> > Is there a way, to set the current record in a TIBDataSet to match a
> > primary search without using "Locate"?

> Not without incurring as much overhead as Locate would.  IBX datasets
> don't (presently) use any kind of circular buffering.  You always have,
> at a minimum, the first record and every record up to the current record
> in memory.

> This corresponds rather closely with how fetching in InterBase works.
> You can't fetch bidirectionally or jump to the middle of a SELECTion.
> To "go to the middle" you'd have to write a new query and execute that.

This is correct. It requires the dataset implementation to have the smarts
to use parameterized queries internally to virtualize the larger dataset in
an efficient way. One ascending and one descending in just the right way to
efficiently fetch only the needed records and thus benefit from indexes in
the process.

Quote
> > TIBDataSet.Locate would do it, but I learnt: it doesn't use index, hence
> > it takes too long.

> In this case, your dataset is too large.  In general, I consider it a
> bad practice to present the user with more than a couple hundred records
> in a list.  It's too much to scroll through.  When your result sets get
> this big, you need to give the user tools to reduce the size of the
> result set.  For example, instead of showing the user all payroll
> records in a week, I give them a screen with tabs for each day of the
> week.  It makes it much easier to find the record they're searching for.

This is nice where there is a limiting context like days, but in many cases
there isn't such a luxury. Take a lookup combo box for example. What if you
could select any name from among 500,000? The answer nowdays is don't use a
lookup combo but with a properly implemented dataset you can use it and the
table size doesn't matter any longer.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Re:TIBDataSet.Locate, set current record


Hi Jason!

I understood very clearly, what you described to me.
And I do also see the problem that is in the IBX-dataset-implementation.
I' m nearly convinced now to take a closer look at IBOjects.

I had to start somewhere, and I started with IBX which has - IMHO - a good
look and feel.
Do IBObjects and IBX cooperate?

Thank you for your time and patience.

Regards,

Jason Wharton schrieb:

Quote
> What part about my earlier post didn't you understand? I thought I gave a
> very clear and detailed explanation of this.

Re:TIBDataSet.Locate, set current record


"Boris Schlszler" <bo...@ts-autovermietung.de> schreef in bericht
news:3C04DC2D.1BF74B06@ts-autovermietung.de...

Quote
> Hi Jason!

> I understood very clearly, what you described to me.
> And I do also see the problem that is in the IBX-dataset-implementation.
> I' m nearly convinced now to take a closer look at IBOjects.

> I had to start somewhere, and I started with IBX which has - IMHO - a good
> look and feel.
> Do IBObjects and IBX cooperate?

IBObjects and IBX both use their own connection components. IBO does have a
TDataset descendant for compatibility with 3rd party products that depend on
it, just like IBX and is more compatible with the BDE components. Migrating
from the BDE to IBO can be done in minutes, if not seconds!

IBO is more than just connectivity (as Jason already told you) - it also has
a very complete set of data-aware components (not compatible with TDataset)
that give you a lot of power and great features to radically develop an
application with IBO and InterBase. Be sure to give it a try!

--
Martijn Tonies
Upscene Productions

InterBase Workbench - The Developer Tool for InterBase
http://www.interbaseworkbench.com

"Experience is what you get when you didn't get what you wanted"

Re:TIBDataSet.Locate, set current record


Quote
Boris Schlszler wrote:

> Do IBObjects and IBX cooperate?

        It's highly unlikely that you'd want to use both in a single
application.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

Re:TIBDataSet.Locate, set current record


Quote
Jason Wharton wrote:

> This is nice where there is a limiting context like days, but in many cases
> there isn't such a luxury. Take a lookup combo box for example. What if you
> could select any name from among 500,000? The answer nowdays is don't use a
> lookup combo but with a properly implemented dataset you can use it and the
> table size doesn't matter any longer.

        I just don't think it's the right control for the job.  Why give people
even the *possibility* of scrolling through 500,000 names?  It doesn't
make any sense.  In one way or another they have to narrow their search,
whether it's through an incremental search or whatever.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

Re:TIBDataSet.Locate, set current record


Quote
> I just don't think it's the right control for the job.  Why give people
> even the *possibility* of scrolling through 500,000 names?  It doesn't
> make any sense.  In one way or another they have to narrow their search,
> whether it's through an incremental search or whatever.

Of course things are narrowed down. That is exactly my point. The difference
between what you are suggesting and what I am suggesting is who does the
work. In your apps, you the programmer muck around and fiddle something
together. Parsing your SQL, plugging in parameter values, opening and
closing datasets, and so on.

What I am suggesting is they give the general SQL for the whole potential
range of records, even if it is quite a large number of them, and then
simply use the ease of stock data aware control, pick lists, etc. and leave
the hard work up to the dataset. One static SQL statement and the dataset
does the rest.

You suggest I think the person is actually going to hit page down through
500,000 records and that is totally absurd. Of course they are going to
limit things. The Locate() method works wonders for helping people find what
they want. There is no reason the dataset cannot be smart about doing their
"narrowing" for them, I know because mine does. And in some circumstances so
did the BDE.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Re:TIBDataSet.Locate, set current record


I agree with you, Jason.
That's exactly my point.

Jason Wharton schrieb:

Quote
> What I am suggesting is they give the general SQL for the whole potential
> range of records, even if it is quite a large number of them, and then
> simply use the ease of stock data aware control, pick lists, etc. and leave
> the hard work up to the dataset. One static SQL statement and the dataset
> does the rest.

Re:TIBDataSet.Locate, set current record


Quote
Jason Wharton wrote:

> Of course things are narrowed down. That is exactly my point. The difference
> between what you are suggesting and what I am suggesting is who does the
> work. In your apps, you the programmer muck around and fiddle something
> together. Parsing your SQL, plugging in parameter values, opening and
> closing datasets, and so on.

        There are two differences:

1.  Who does the work.
2.  How the result is presented to the end user.

        I was addressing (2) and not (1).  You appear to be referring to (1).

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
We're hiring: http://www.vertexsoftware.com/careerops.htm#sd
     Delphi/InterBase WebLog: http://delphi.weblogs.com

Re:TIBDataSet.Locate, set current record


Quote
> > Of course things are narrowed down. That is exactly my point. The
difference
> > between what you are suggesting and what I am suggesting is who does the
> > work. In your apps, you the programmer muck around and fiddle something
> > together. Parsing your SQL, plugging in parameter values, opening and
> > closing datasets, and so on.

> There are two differences:

> 1.  Who does the work.
> 2.  How the result is presented to the end user.

> I was addressing (2) and not (1).  You appear to be referring to (1).

I am simply keeping to the point of this thread, as the subject line
indicates.

You once told me you don't help people by suggesting they use an entirely
different piece of technology that they are endeavoring to use. This person
wants to use the Locate() method, not rewrite their entire GUI and use
something like DataSnap and its plethora of added layers and complexity.

An efficient well-designed Locate() is all they need.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Go to page: [1] [2]

Other Threads