I'm adding a new feature to my main app. One of the forms is a project list - a list of people to call. The lists are built manually(ish) from the full list of contacts & companies on the system. When a project is selected the application builds a chunk of sql which extracts fields from the various tables and build the working list as an in-memory table. Various indices are created for the in-memory table.

The new feature is a couple of indices - most recent calls and least recent calls (_LastDialed DESC & _LastDialed).

When the index in use is least recent calls then I have a problem. When any call result is recorded (which may be - not available - in a meeting or an actual conversation) the _LastDialed info is updated, the record wizzes down to the bottom of the table which is fair enough BUT I simply want to go to what was the next record BEFORE the updated one is moved due to the indexed field change.

Any thoughts on how best to accomplish this?


Roy Lambert

Roy,

<< Any thoughts on how best to accomplish this? >>

I would grab a bookmark right before updating row, and then go to that bookmark after the row has been updated.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

I've probably explained it badly.

Given rows
1 12/10/2013
2 01/02/2015
3 19/12/2016
4 07/12/2016
5 02/12/2016

Row 2 gets altered so the sequence is now
1 12/10/2013
3 19/12/2016
4 07/12/2016
5 02/12/2016
2 26/07/2017

and I want the cursor to end up at Row 3 (wish I'd thought to explain it that way before)

>I would grab a bookmark right before updating row, and then go to that bookmark after the row has been updated.

I thought that would take me to Row 2.

What I currently have is

procedure TProjectForm.ProjectBeforeEdit(DataSet: TDataSet);
begin
if Project.Tag in [7, 8] then begin
 if not NextOne.Prepared then begin
  NextOne.SQL.Text := 'SELECT _CallID FROM ' + Project.TableName + ' ORDER BY _LastDialed';
  if Project.Tag = 7 then NextOne.SQL.Text := NextOne.SQL.Text + ' DESC';
  NextOne.Prepare;
  NextOne.ExecSQL;
 end else NextOne.Refresh;
 if NextOne.Locate('_CallID', Project_CallID.AsInteger, []) then begin
  NextOne.Next;
  NextCallID := NextOne.FieldByName('_CallID').AsInteger;
 end else NextCallID := -1;
end;
end;

and then

procedure TProjectForm.JumpToNextCallIDWanted;
begin
CallsEdited := False;
if (Project.Tag in [7, 8]) and (NextCallID <> -1) then Project.Locate('_CallID', NextCallID, []);
NextCallID := -1;
end;

in various places.

With something like this I find myself longing for the days os simple procedural programming. Some of my forms get sufficiently complex that it becomesmore  a matter of trial and error than logic to determine where to do things. In this case there are only 4 locations I have to call JumpToNextCallIDWanted to make it work. Can't do it in the Project AfterPost event cos that screws other stuff up.


Ah well rant over for another day

Roy

Roy

I read Tim's suggestion as:
before posting the update to the current record, bookmark the next
record in your sequence, then update the current record, then goto
bookmark.

So, in TTable terms it would look like:
 1. store change
 2. Table.Next
 3. Save Bookmark
 4. Table.Previous
 5. Table.Edit
 6. Table.Post
 6. Goto Bookmark

Or something like that ... maybe.  

Malcolm,

<< I read Tim's suggestion as:
before posting the update to the current record, bookmark the next
record in your sequence, then update the current record, then goto
bookmark. >>

That's correct.  Roy, you may need to use a separate table instance to make this all function smoothly without interrupting the update flow on the current table, but it *will* work. You can definitely use a bookmark from one table instance with another table instance, but you must make sure that the second table instance is using the same active index, otherwise the bookmarks *will* be different and you'll end up with incorrect behaviors.

Something like this:

MyTableCopy.IndexName:=MyTable.IndexName;
MyTableCopy.GotoCurrent(MyTable);
MyTableCopy.Next;
MyTableCopy.GetBookmark;

Tim Young
Elevate Software
www.elevatesoft.com

Tim


>That's correct. Roy, you may need to use a separate table instance to make this all function smoothly without interrupting the update flow on the current table, but it *will* work. You can definitely use a bookmark from one table instance with another table instance, but you must make sure that the second table instance is using the same active index, otherwise the bookmarks *will* be different and you'll end up with incorrect behaviors.

Its sort of like what I'm doing with the exception I'm using a query and grabbing the primary key. I discarded anything like this to start with because an update to the table I'm interested in results in updating four other tables at present. I was also trying to keep memory usage down - I didn't succeed

Thanks for your and Malcolm's input

Roy