Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 21 to 30 of 31 total |
Inserting Record Efficiently |
Fri, May 25 2007 2:11 AM | Permanent Link |
"Bobby Gallagher" | 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 > |
Fri, May 25 2007 2:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Fri, May 25 2007 2:51 PM | Permanent Link |
Norman L. Kleinberg | 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 |
Thu, May 31 2007 9:42 AM | Permanent Link |
Chris Erdal | 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) |
Thu, May 31 2007 10:09 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Thu, May 31 2007 10:34 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Thu, May 31 2007 1:51 PM | Permanent Link |
Chris Erdal | 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) |
Thu, May 31 2007 1:56 PM | Permanent Link |
Chris Erdal | 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) |
Sun, Jun 3 2007 10:18 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sun, Jun 3 2007 11:48 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Correction. The fastest way is a master - detail relationship for the table and a while not eof loop to stuff the grid
Roy Lambert |
« Previous Page | Page 3 of 4 | Next Page » |
Jump to Page: 1 2 3 4 |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |