Board index » delphi » SelectedRows Property

SelectedRows Property

I want to mark all rows on a grid as 'selected' as though they had been
selected by the user. I have 'selectrows' and multiselect set to 'true'. Is
there a method for this or do I have to loop through the query object that
the grid is bound to. Also, I noticed that if I want to set a certain field
in all rows of a query to a fixed values ,, say ....
fieldbyname('status').asstring := 'Open',

then the process is slow, slow, slow.  THe querry is set for cashed updates
with an update object built.  Is that what makes it so slow ? If I set the
querry for 'one direction' it goes about 50 % faster but neither way is as
fast as just doing a sql against the database and setting the values there,
then reselecting all the records. This takes about 3 seconds and the first
way about 3 minutes. Could you explain ?

Thanks,
Del
d...@emerald-coast.org

 

Re:SelectedRows Property


Quote
>I want to mark all rows on a grid as 'selected' as though they had been
>selected by the user. I have 'selectrows' and multiselect set to 'true'. Is
>there a method for this or do I have to loop through the query object that
>the grid is bound to.

You will have to loop through all records

Quote
> Also, I noticed that if I want to set a certain field
>in all rows of a query to a fixed values ,, say ....
>fieldbyname('status').asstring := 'Open',

>then the process is slow, slow, slow.  THe querry is set for cashed updates
>with an update object built.  Is that what makes it so slow ?

That is a lot slower than using a single Update Query

Quote
>If I set the
>querry for 'one direction' it goes about 50 % faster but neither way is as
>fast as just doing a sql against the database and setting the values there,
>then reselecting all the records. This takes about 3 seconds and the first
>way about 3 minutes. Could you explain ?

With an updateSQL object there will be a query executed for each record that is
changed.  Doing an SQL query against the database is a single query.
The reason for the difference should be obvious.   I query per tables is faster
than one query for each record.

--
Brian Bushay (TeamB)
Bbus...@NMPLS.com

Re:SelectedRows Property


Yes, but I'm not applying updates after each record is changed. The code
looks like this...

with qryMaster do
    begin
        while not eof do
            begin
                fieldbyname('status').asstring := 'Closed';
                next;
            end;
     end;

The above takes a long time, not the apply updates. The cashed query only
has 150 records.
when I do apply updates, it actually writes and commits the data very fast.
(1sec).

tks.

Quote
Brian Bushay TeamB wrote in message <3812e6fa.50836431@floyd>...
>>I want to mark all rows on a grid as 'selected' as though they had been
>>selected by the user. I have 'selectrows' and multiselect set to 'true'.
Is
>>there a method for this or do I have to loop through the query object that
>>the grid is bound to.
>You will have to loop through all records

>> Also, I noticed that if I want to set a certain field
>>in all rows of a query to a fixed values ,, say ....
>>fieldbyname('status').asstring := 'Open',

>>then the process is slow, slow, slow.  THe querry is set for cashed
updates
>>with an update object built.  Is that what makes it so slow ?
>That is a lot slower than using a single Update Query

>>If I set the
>>querry for 'one direction' it goes about 50 % faster but neither way is as
>>fast as just doing a sql against the database and setting the values
there,
>>then reselecting all the records. This takes about 3 seconds and the first
>>way about 3 minutes. Could you explain ?
>With an updateSQL object there will be a query executed for each record
that is
>changed.  Doing an SQL query against the database is a single query.
>The reason for the difference should be obvious.   I query per tables is
faster
>than one query for each record.

>--
>Brian Bushay (TeamB)
>Bbus...@NMPLS.com

Re:SelectedRows Property


Quote
>The above takes a long time, not the apply updates. The cashed query only
>has 150 records.
>when I do apply updates, it actually writes and commits the data very fast.
>(1sec).

Is your query a RequestLive query?
If so turn off request live and your iteration through the table should be a lot
faster.

--
Brian Bushay (TeamB)
Bbus...@NMPLS.com

Re:SelectedRows Property


No, it is a cached updates query. That's what is so strange. Everyone that
repsonds seems to be missing that and implying that in a cached update query
as you move from record to record in the result set that a 'query' is being
done back to the real database to refetch the record and I just cant believe
that to be true. I wait until I have done all my updates in the cursor
(tquery object) then I 'applyupdates'. I maintain concurrency that way. Is
it true that if I set 'updatewhere' to 'changed' that Delphi will post an
exception if someone else has updated the particular field I have changed
but post the exception if the field in the database has changed but I have
not modified it in my cursor ?

Thanks,

Quote
Brian Bushay TeamB wrote in message <381a4197.38646651@floyd>...
>>The above takes a long time, not the apply updates. The cashed query only
>>has 150 records.
>>when I do apply updates, it actually writes and commits the data very
fast.
>>(1sec).

>Is your query a RequestLive query?
>If so turn off request live and your iteration through the table should be
a lot
>faster.

>--
>Brian Bushay (TeamB)
>Bbus...@NMPLS.com

Re:SelectedRows Property


Quote
>No, it is a cached updates query. That's what is so strange.

Using cached updates does not preclude you from setting requestLive to true

Quote
>Is it true that if I set 'updatewhere' to 'changed' that Delphi will post an
>exception if someone else has updated the particular field I have changed
>but post the exception if the field in the database has changed but I have
>not modified it in my cursor ?

UpdateWhereChanged uses key fields plus the fields that have changed to locate
the record to modify.  If these values have been changed by another user you
would get an exception.  If fields you have not changed are modified by another
user there won't be an exception.

--
Brian Bushay (TeamB)
Bbus...@NMPLS.com

Re:SelectedRows Property


Brian,
I'm trying to learn how this really works ... so bear with me.  If the
generated sql statements in the update object say '..... where id = :0ld_id
.....  (The table has an autonumber field as a unique index) then why would
the updatewhere properties come into play ? Is there someplace I can go to
find out the internals of how cached updates operates ?

Quote
Brian Bushay TeamB wrote in message <38332ca1.47150996@floyd>...

>>No, it is a cached updates query. That's what is so strange.
>Using cached updates does not preclude you from setting requestLive to true

>>Is it true that if I set 'updatewhere' to 'changed' that Delphi will post
an
>>exception if someone else has updated the particular field I have changed
>>but post the exception if the field in the database has changed but I have
>>not modified it in my cursor ?

>UpdateWhereChanged uses key fields plus the fields that have changed to
locate
>the record to modify.  If these values have been changed by another user
you
>would get an exception.  If fields you have not changed are modified by
another
>user there won't be an exception.

>--
>Brian Bushay (TeamB)
>Bbus...@NMPLS.com

Re:SelectedRows Property


Quote
> where id = :0ld_id
>.....  (The table has an autonumber field as a unique index) then why would
>the updatewhere properties come into play ?

It all depends if you care if other users modify the record while it is in your
cache waiting to be updated.  If you want a change rejected because the original
record was modified by another user choose one of the more restrictive methods.
If all you care about is the last user to change it wins use wherekeyOnly

Quote
> Is there someplace I can go to
>find out the internals of how cached updates operates ?

Not that I know of.  Cached updates is old technology and I would not want to
encourage you to use it.   A much better solution is to use a tClientDataset.

--
Brian Bushay (TeamB)
Bbus...@NMPLS.com

Re:SelectedRows Property


AH HA ....

So ... for cached updates the wherechanged property controls when an
exception gets posted, not how the data record to update is located. The
documentation say that is controls how the  records to be updated are
'found' ... which is confusing. Anyway, I've got it.

Quote
Brian Bushay TeamB wrote in message <383574a9.26967718@floyd>...

>> where id = :0ld_id
>>.....  (The table has an autonumber field as a unique index) then why
would
>>the updatewhere properties come into play ?
>It all depends if you care if other users modify the record while it is in
your
>cache waiting to be updated.  If you want a change rejected because the
original
>record was modified by another user choose one of the more restrictive
methods.
>If all you care about is the last user to change it wins use wherekeyOnly

>> Is there someplace I can go to
>>find out the internals of how cached updates operates ?
>Not that I know of.  Cached updates is old technology and I would not want
to
>encourage you to use it.   A much better solution is to use a
tClientDataset.

>--
>Brian Bushay (TeamB)
>Bbus...@NMPLS.com

Other Threads