Subject | Well Helen .. Solved my problem with unusual IB_Grid behaviour thanks to your advice. Please comment on the text. |
---|---|
Author | adrian |
Post date | 2004-06-22T18:53:01Z |
Dear Helen.
I studied the GSG .. and benefited the following: (I always ignored it
as dated 2002)
I always used IB_database, but now use IB_Connect as Jason quite
correctly points out.
Following the thread on [IBO] Absolute unique value/generator/SP
problem, I noticed I'm not the only one who uses generated keys for
sequential record numbers.
I also have the problem of someone canceling, then the generator ID has
been moved on by +1, thus the gaps. That is why I was using the before
after events on the controlbar.
Well I did what you said, and used the Dataset.beforepost etc events to
do just the same, and this time the Grid displayed the last column
entered that I was having a problem with.
Using the PK for the file number ie thus a DATA_Column, which is
probably herecy, I get excellent concurrency using the method (adapted)
below.
The only problem, is if a file is deleted, then the file number is lost.
This happens in the real world scenario when a secretary enters an
existing client without checking if they are already on the database.
What I then do, is either reset the generatorID, or if other records
have been added, then I cook it in the database. Obviously this requires
data editing tools like IBAdmin.
Sofar this has worked without one hitch for over 5600 files. The only
problem is with the cancels. Note I pick up on edits to prevent the
generator from being fired on posts after edits.
PS I agree, what could be easier than just using the generatorlinks, as
this will supply you with the PK everytime, as with old paradox
autoincremental fields!
But I use the PK as a data field (herecy), and need more control over
it, thus the method used.
Your comments please.
Thanks
Adrian
Code follows:
procedure TForm1.IB_QueryPERFORMANCEBeforePost(IB_Dataset: TIB_Dataset);
begin
If NewPERFId then
begin
IPERFId := GetNewId('PERFORMANCE');
IB_QueryPERFORMANCE.FieldByName('PERFORMANCEID').AsInteger :=
IPERFId;
end
end;
procedure TForm1.IB_QueryPERFORMANCEAfterInsert(IB_Dataset:
TIB_Dataset);
begin
NewPERFID := True;
end;
procedure TForm1.IB_QueryPERFORMANCEAfterCancel(IB_Dataset:
TIB_Dataset);
begin
NewPERFID := True;
end;
procedure TForm1.IB_QueryPERFORMANCEAfterPost(IB_Dataset: TIB_Dataset);
begin
IPERFId := IB_QueryPERFORMANCE.FieldByName('PERFORMANCEID').AsInteger;
IB_QueryPERFORMANCE.Close;
IB_QueryPERFORMANCE.Open;
IB_QueryPERFORMANCE.Locate('PERFORMANCEID',IPERFId,[]);
NewPERFId := False;
end;
procedure TForm1.IB_QueryPERFORMANCEAfterEdit(IB_Dataset: TIB_Dataset);
begin
NewPERFID := False;
end;
[Non-text portions of this message have been removed]
I studied the GSG .. and benefited the following: (I always ignored it
as dated 2002)
I always used IB_database, but now use IB_Connect as Jason quite
correctly points out.
Following the thread on [IBO] Absolute unique value/generator/SP
problem, I noticed I'm not the only one who uses generated keys for
sequential record numbers.
I also have the problem of someone canceling, then the generator ID has
been moved on by +1, thus the gaps. That is why I was using the before
after events on the controlbar.
Well I did what you said, and used the Dataset.beforepost etc events to
do just the same, and this time the Grid displayed the last column
entered that I was having a problem with.
Using the PK for the file number ie thus a DATA_Column, which is
probably herecy, I get excellent concurrency using the method (adapted)
below.
The only problem, is if a file is deleted, then the file number is lost.
This happens in the real world scenario when a secretary enters an
existing client without checking if they are already on the database.
What I then do, is either reset the generatorID, or if other records
have been added, then I cook it in the database. Obviously this requires
data editing tools like IBAdmin.
Sofar this has worked without one hitch for over 5600 files. The only
problem is with the cancels. Note I pick up on edits to prevent the
generator from being fired on posts after edits.
PS I agree, what could be easier than just using the generatorlinks, as
this will supply you with the PK everytime, as with old paradox
autoincremental fields!
But I use the PK as a data field (herecy), and need more control over
it, thus the method used.
Your comments please.
Thanks
Adrian
Code follows:
procedure TForm1.IB_QueryPERFORMANCEBeforePost(IB_Dataset: TIB_Dataset);
begin
If NewPERFId then
begin
IPERFId := GetNewId('PERFORMANCE');
IB_QueryPERFORMANCE.FieldByName('PERFORMANCEID').AsInteger :=
IPERFId;
end
end;
procedure TForm1.IB_QueryPERFORMANCEAfterInsert(IB_Dataset:
TIB_Dataset);
begin
NewPERFID := True;
end;
procedure TForm1.IB_QueryPERFORMANCEAfterCancel(IB_Dataset:
TIB_Dataset);
begin
NewPERFID := True;
end;
procedure TForm1.IB_QueryPERFORMANCEAfterPost(IB_Dataset: TIB_Dataset);
begin
IPERFId := IB_QueryPERFORMANCE.FieldByName('PERFORMANCEID').AsInteger;
IB_QueryPERFORMANCE.Close;
IB_QueryPERFORMANCE.Open;
IB_QueryPERFORMANCE.Locate('PERFORMANCEID',IPERFId,[]);
NewPERFId := False;
end;
procedure TForm1.IB_QueryPERFORMANCEAfterEdit(IB_Dataset: TIB_Dataset);
begin
NewPERFID := False;
end;
[Non-text portions of this message have been removed]