DBISAM 3.30

I have two tables Sales and Customers. Customers and Sales are
"linked" by the common field CustomerID. Now in the
tblCustomersBeforeDelete event I delete all records in Sales that have
the CustomerID being deleted. I use a tblSales .FindKey on the deleted
CustomerID to make sure there are related records first. Now when I
delete a customer record from a DBGrid tied to a DBNavigator it is the
record below the selected ID that is actually deleted. When I comment
out the Findkey line in tblCustomersBeforeDelete the correct record is
deleted. Any ideas as to what is going on here?

Michael

A bit of a guess, but it sounds like the Customers table cursor is
being moved.

When FindKey eventually fails to find any more sales records it will
end up on the next record in the sales table.  Does that cause the
Customer to be changed to match the sales record?

Malcolm

On Wed, 3 Oct 2007 18:58:35 -0500, "Malcolm"
<malcolm@spam.will.bounce> wrote:

>Michael
>
>A bit of a guess, but it sounds like the Customers table cursor is
>being moved.

Yes its being moved by Sales.FindKey which is bizarre.

>When FindKey eventually fails to find any more sales records it will
>end up on the next record in the sales table.  Does that cause the
>Customer to be changed to match the sales record?

In my tests the FindKey always succeeds. I am not using any sort of
Master/Detail methodology if that's what you mean. Customers is just a
lookup table.

Michael,

What's the code look like in the OnBeforeDelete event?

Regards, Harry

"Michael Fullerton" <fullerm@spamkiller-remove-cybermatrix.com> schreef in
bericht news98g3lbrnf203jff60sa2eeddd2tig0ha@4ax.com...
> On Wed, 3 Oct 2007 18:58:35 -0500, "Malcolm"
> <malcolm@spam.will.bounce> wrote:
>
> >Michael
> >
> >A bit of a guess, but it sounds like the Customers table cursor is
> >being moved.
>
> Yes its being moved by Sales.FindKey which is bizarre.
>
> >When FindKey eventually fails to find any more sales records it will
> >end up on the next record in the sales table.  Does that cause the
> >Customer to be changed to match the sales record?
>
> In my tests the FindKey always succeeds. I am not using any sort of
> Master/Detail methodology if that's what you mean. Customers is just a
> lookup table.
>

On Thu, 4 Oct 2007 07:30:12 +0200, "Harry de Boer" <harry@staaf.nl>
wrote:

>Michael,
>
>What's the code look like in the OnBeforeDelete event?

Like this Harry:

procedure TDM.tblCustomersBeforeDelete(DataSet: TDataSet);
var
 s: string;
begin
 s:= DataSet.FieldByName('CustomerID').AsString;
 OpenTable(DM.tblSales);
 tblSales.IndexName:= 'CustomerID';
 if tblSales.FindKey([s]) then
   if (Application.MessageBox(PChar(Translate('Do you wish to delete
all records containing this CustomerID in all linked tables as
well?')),PChar(Translate('Confirmation')),
     MB_YESNO or MB_ICONQUESTION or MB_SYSTEMMODAL) = IDYES) then
begin
     with qryRI do begin
       Close;
       SQL.Text:= 'DELETE FROM Sales WHERE CustomerID =
'+QuotedStr(s);
       ExecSQL;
     end;
   end;
 tblSales.IndexName:= '';
end;

>Regards, Harry
>
>"Michael Fullerton" <fullerm@spamkiller-remove-cybermatrix.com> schreef in
>bericht news98g3lbrnf203jff60sa2eeddd2tig0ha@4ax.com...
>> On Wed, 3 Oct 2007 18:58:35 -0500, "Malcolm"
>> <malcolm@spam.will.bounce> wrote:
>>
>> >Michael
>> >
>> >A bit of a guess, but it sounds like the Customers table cursor is
>> >being moved.
>>
>> Yes its being moved by Sales.FindKey which is bizarre.
>>
>> >When FindKey eventually fails to find any more sales records it will
>> >end up on the next record in the sales table.  Does that cause the
>> >Customer to be changed to match the sales record?
>>
>> In my tests the FindKey always succeeds. I am not using any sort of
>> Master/Detail methodology if that's what you mean. Customers is just a
>> lookup table.
>>
>

"Michael Fullerton" <fullerm@spamkiller-remove-cybermatrix.com> wrote in
message news98g3lbrnf203jff60sa2eeddd2tig0ha@4ax.com...
> Master/Detail methodology if that's what you mean. Customers is just a
> lookup table.
>

This has to be the problem. Instead of the findkey, use your query to first
select records from sales, then if not query.isempty do the dialog and the
delete. You need to avoid references to te sales table, or you'll move the
cursor in customers.

Robert

Michael,

<< I have two tables Sales and Customers. Customers and Sales are "linked"
by the common field CustomerID. Now in the tblCustomersBeforeDelete event I
delete all records in Sales that have the CustomerID being deleted. I use a
tblSales .FindKey on the deleted CustomerID to make sure there are related
records first. >>

As Robert indicated, this is your problem.  The FindKey is moving the record
pointer for the Sales table, and that is then causing the Customers table
linkage to be refreshed and the record pointer for the Customers table will
be moved back to the beginning.

--
Tim Young
Elevate Software
www.elevatesoft.com

On Thu, 4 Oct 2007 11:12:12 -0500, "Tim Young [Elevate Software]"
<timyoung@elevatesoft.com> wrote:

>Michael,
>
><< I have two tables Sales and Customers. Customers and Sales are "linked"
>by the common field CustomerID. Now in the tblCustomersBeforeDelete event I
>delete all records in Sales that have the CustomerID being deleted. I use a
>tblSales .FindKey on the deleted CustomerID to make sure there are related
>records first. >>
>
>As Robert indicated, this is your problem.  The FindKey is moving the record
>pointer for the Sales table, and that is then causing the Customers table
>linkage to be refreshed and the record pointer for the Customers table will
>be moved back to the beginning.

The only linkage would be a TDBLookUpComboBox on that form where the
delete is initiated. The TDBLookUpComboBox is tied to Sales and
listing Customer values. Sure enough, when I delete the
TDBLookUpComboBox the correct record is deleted. So is this a bug or
an undocumented "feature" of TDBLookUpComboBox?

"Michael Fullerton" <fullerm@spamkiller-remove-cybermatrix.com> wrote in
message news:ug3ag39dsjkiqd4lekst0r8vgf90bofoqq@4ax.com...
> TDBLookUpComboBox the correct record is deleted. So is this a bug or
> an undocumented "feature" of TDBLookUpComboBox?
>

Neither. That's the way it works. Use SQL on a fresh query not linked to
anything, to avoid these problems.

Robert