This is using the 155 developers build, and the same bit of code as my
previous post.
Here is the full basic procedure that I called:
sub onClickApplyAllAdjustments( oEv as variant )
dim tmpAdjustments as variant
tmpAdjustments = oEv.Source.Model.Parent
with tmpAdjustments
if .RowInserted then
.InsertRow
end if
do
.First
spInvAdjustment(tmpAdjustments.Columns.getByName("ProductID").getInt
, _
tmpAdjustments.Columns.getByName("AdjDate").getDate,
_
tmpAdjustments.Columns.getByName("AdjType").getInt, _
tmpAdjustments.Columns.getByName("Units").getInt, _
tmpAdjustments.ActiveConnection )
.DeleteRow
loop until .isBeforeFirst
end with
end sub
The procedure was called from an event assigned to a button on an
embedded from. As I said
in my last message I was unable to call it with an inserted row in the
table. So I went ahead and
tested it with a couple of rows that had all been saved to the table.
The routine ran successfully for each row in the table, calling the
spInvAdjustment routine and
deleting each row in the attached table - unitl the last row had been
deleted.
isBeforeFirst failed to return TRUE at this point - perhaps I am wrong
in thinking that it should, and
this is not the right way to handle this.
However - at the next call to First it generated an "Abnormal Program
Termination".
Upon restart the file recovery process began, I let it run. At the last
step I went to review
the crash report, so that I could keep a copy to possibly attach to an
issue entry. The report
was blank. I then went ahead and told it to send it to SUN as usual -
this caused an "Abnormal
Program Termination" error dialog on the crash recovery executable.
At this point the database file finished opening. The form is gone.
The other tables and forms in the file are still there as is the data.
Just not quite
the right data.
The table that was having the records deleted was recoverd with one
record still
in it. The procedure spInvAdjustment actually updates two other tables
in the database.
The data in these is now not inaccurate. The table that received copies
of the records from
the temporary table no longer have these records, they have been lost in
the crash,(this after stepping through the code
and watching the updates happen) the other process was to update a
column in a second table based
on the type of transaction record. That columns value is now set as if
all the transactions had been saved, the transactions
that are now gone that is. All this happened with Autocommit set to true.
Losing the form I understand, don't like but understand, because I can't
say for certain that I saved the
database file after I created (and saved) the form. I should know
better at this point.
The situation with the data is more of a problem however. I don't want
to beat a dead horse here, and I would be
stupid to run this kind of a routine against a live database, for the
fist time. But the crash recovery needs to be consistent.
In my temp table I had two records. I watched both be deleted. One was
recovered. The one that was lost, is really lost.
The records where inserted into a second table. Both where lost. A table
had a columns value updated twice, it recovered this
changed value.
The other point however is this. Even if my code is wrong from a logic
stand point it really should not be generating
a program termination.
So, want me to open an issue and send up the databse and the basic routines?
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
