Hi Tim

Does all of the above comments / answers apply to DBISAM V3 i.e. if I run  a
query on a table in a C/S app with session.sessiontype = stRemote - is that
all I need to do the have the query run on the server and only the resultset
returned over the net

Regards

Bobby


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:72166306-0E4A-479B-A871-014E7C39B78D@news.elevatesoft.com...
> Norman,
>
> << Thanks for chiming in. When you say "that's incorrect" I'm inferring
> that you mean a limited number of records are sent over the wire with
> EITHER Query or Table components (as opposed to my thinking that it was
> only the Query). >>
>
> Correct.  All TDataSet-descendant components in DBISAM work the same way
> with respect to how records are fetched from the database server.
>
> << But that begs a question (sorry if I'm being dense here): when I Open a
> T(DBISAM)Query with a WHERE clause requesting, say, ONE record I can see
> how only ONE record will be sent. But when I open a T(DBISAM)Table, how
> are the records limited? >>
>
> They are limited by two things:
>
> 1) How many records are required to populate a data-aware control (i.e.
> grid may need 10 records, but an edit will only need 1 at a time)
>
> and
>
> 2) The setting of the RemoteReadSize property
>
> whichever of the two is bigger is the number that DBISAM uses to determine
> how many records to fetch from the database server.
>
> << Is it that the act of OPENING a TTable doesn't send ANYTHING over the
> wire? >>
>
> By itself, no.  The actual fetching of the records is another
> request/response.
>
> << What happens then when I, say, try to FIND a record in a TTable? Is the
> searching done remotely and only the resulting record sent? >>
>
> Correct.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Bobby,

<< Does all of the above comments / answers apply to DBISAM V3 i.e. if I run
a query on a table in a C/S app with session.sessiontype = stRemote - is
that all I need to do the have the query run on the server and only the
resultset
returned over the net >>

Yes.  And as an aside - EDB is even better in this respect since it can
navigate cached rows on the client bi-directionally, so as long as the row
you're viewing is in the "window" of cached rows, it will not request any
more rows from the ElevateDB Server when using next/prior navigation.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

OK, thanks for taking the time to post that info.

But then "all this talk" about using Queries instead of Tables when dealing with remote
databases boils down to, mainly, the problem of loading up a data-aware grid? Doesn't it
depend on how many records the grid asks for (aside from RemoteReadSize, I understand
that). So that if you have a grid that "asks" for only a page of, say, 10 records at a
time you're OK but if for some reason the grid is designed to cache the whole dataset
locally (e.g. DevExpress in some incarnations) one would restrict that with a Query?

Or is it that DBISAM is different from, say, TTable so that the "usual rules" don't apply
(i.e. DBISAM acts more like a Remote Server than other systems)?

Appreciate any additional info. I think I'm getting this now.


Norman

Norman,

I've been away in the Inner Hebrides (Iona and Morvern) for the last
couple of weeks, so I'm just catching up here.

Norman L. Kleinberg <nlk11021@yahoo.com> wrote in
news:EA9F7D08-90F3-4963-94CA-0C604F6117E4@news.elevatesoft.com:
>...
>>This means that, in view of the onBeforePost event for tblMaster, when
>>I am about to post a new row in tblMaster (which will be lost as it's
>>a CANNED query) I open updQuery onto an empty row in the REAL table
>>(as the key doesn't yet exist in the REAL table on the disk), and
>>immediately put it into the Insert state, transfer all the required
>>field values to it, and Post it.
>
> This is the crux of my misunderstanding. What is your WHERE clause for
> this? Is it aKeyField := "whatever the new key is"? If so, and the
> table has an AutoInc primary key, how do you know what this value will
> be? For example, say I have an AutoInc CustomerID in my table. User
> hits Insert: the canned query BeforePost event opens the Query on an
> empty row, which I presume is accomplished by a WHERE clause such as
> KeyField = "new Key Field". But how do you know what that "new Key
> Field" is if it's AutoInc? I guess I'm asking what your WHERE
> clause looks like when you are opening the Query on an empty row.
>
> If the table has an AutoInc key then you won't KNOW the new key value
> until you Post the record, I
> believe.

I realise this is all a little complicated, but I'm very good at
complicating where others find a simple way to do things!

Anyway, here are a few essentials:

1/ I don't use a data-aware grid for the main query, but copy all the
rows to an AdvStringGrid to give me more freedom in presenting the data.

2/If the main query is live, I just use it directly and ignore my
updQuery method, but I still need to update the grid when necessary since
it is not data-aware.

3/ When I want to insert a new record, I put my canned query into insert
mode. This clears all the fields, including the ID field, so my linked
updQuery (which is linked by the ID field to the main table in the canned
query) contains an empty set. I then allow the user to insert a new row
into the canned query (*** this won't be possible any more when I move
over to EDB ***), and in the onPost event I set the updQuery (which is
live on the main table) to Insert mode and copy all the field values to
it, and then post to updQuery.

> I of course have no doubt it works but I can't see how if the table
> has an AutoInc key. Again, my
> understanding is that I won't know the value of that key until after I
> post the Live query

I can now read the newly inserted AutoInc value in updQuery's ID field
and copy it to the canned query's ID field to allow them to stay in sync.

, at which point
> the record disappears (unless you have a WHERE clause I haven't
> envisioned).

At that point I call a function that inserts a blank row in the
AdvStringGrid and copies the current row from the canned query to it.

Don't forget I'm not using a data-aware grid, so I keep the grid up to
date in my code. (I only programmed all this once, in a special Form from
which I inherit all real forms for any application in which I need this
behaviour.)


> Perhaps if you could write out your WHERE clause for an Insert I could
> figure it out.

the where clause for updQuery is simply

WHERE myAutoIncFld = :myAutoIncFld

and when I insert into this dataset I get a row which is still there when
I read its field values.

(I've just understood your problem as I write this: theoretically the row
should no longer be "visible" as the new ID field value is not yet in the
master table. I suppose this is a quirk as the row probably only
disappears when one does a refresh on updQuery, but I've not tried that
out)

I realize it's asking a lot
> so I would understand if you couldn't, it's just this Insert thingie
> has me totally confused.

Thanks for making me delve back into code I wrote six months ago, as I
think you've pointed out a potential bug if Tim decides to follow the
master-detail rules a bit more closely!

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.03 build 1)

Chris


>I've been away in the Inner Hebrides (Iona and Morvern) for the last
>couple of weeks, so I'm just catching up here.

Next time pop into Caithness and say hello


>*** this won't be possible any more when I move
>over to EDB ***

Dead right with the latest changes. I'm in the process of moving over to in memory tables (not as simple as the old DBISAM stuff) and I'm impressed by the speed so far. The biggest problem as far as I can see is that the ORDER BY clause in the select statement used to create the table gets ignored so I'll have to come up with a schema for creating indices as and when necessary.

Thinking about it as I type I may switch to using a TAdvStringGrid. Most of the time there won't be a great time penalty. I shall try some timings.

Roy Lambert

Chris


<<1/ I don't use a data-aware grid for the main query, but copy all the
rows to an AdvStringGrid to give me more freedom in presenting the data.>>

Do you do a navigational with not eof loop through the query and stuff fields in on a cell by cell basis or do you have a better way?


Roy Lambert

Roy Lambert <roy.lambert@skynet.co.uk> wrote in
news:166090D8-9ABB-4E45-9A49-3E98BBF46E7A@news.elevatesoft.com:


>>I've been away in the Inner Hebrides (Iona and Morvern) for the last
>>couple of weeks, so I'm just catching up here.
>
> Next time pop into Caithness and say hello
>

I put that in for you, Roy

thanks for the invitation, but as you know, Caithness is a wee bit further
than Fort William!

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.03 build 1)

Roy Lambert <roy.lambert@skynet.co.uk> wrote in
news:71A0D5CF-CA0B-4F1E-9AA9-79DE92CC9FDE@news.elevatesoft.com:

> Chris
>
>
><<1/ I don't use a data-aware grid for the main query, but copy all the
> rows to an AdvStringGrid to give me more freedom in presenting the
> data.>>
>
> Do you do a navigational with not eof loop through the query and stuff
> fields in on a cell by cell basis

that's exactly it.

> or do you have a better way?

no, sorry. I'm open to any ideas, though.

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.03 build 1)

Chris


This is the fastest way I've managed to com up with. sg is the TAdvStringGrid. I'm testing in fileserver mode since that's how I do most things.


procedure TForm1.DoIt(BoxNo: integer);
var
lc: integer;
begin
sg.BeginUpdate;
ELN.IndexName := 'Company';
sg.ClearRows(1, sg.RowCount - 1);
lc := 1;
if ELN.FindKey([BoxNo]) then begin
 while ELN_fkCompanies.AsInteger = BoxNo do begin
  sg.Cells[4, lc] := ELN_WhoFrom.AsString;
  sg.Cells[3, lc] := ELN_Subject.AsString;
  sg.Cells[2, lc] := ELN_TimeStamp.AsString;
  sg.Cells[5, lc] := ELN_fkUsers.AsString;
  ELN.Next;
  inc(lc);
 end;
end else lc := 2;
sg.RowCount := lc;
sg.FixedRows := 1;
sg.EndUpdate;
end;

Roy Lambert

Correction. The fastest way is a master - detail relationship for the table and a while not eof loop to stuff the grid

Roy Lambert