I have spent many hours stepping through StrataFrame source code and I have discovered a bug that under very simple but specific circumstances causes a record in the local internal data table to be incorrectly deleted immediately after the original record in the backend database table was not deleted because of a legitimate concurrency conflict.  This occurs with no warning message displayed but leaves the data in the local internal data table showing that the record has been deleted, but the backend database table showing that the record was NOT deleted.

The bug occurs in unmodified StrataFrame source code when attempting to delete a record from a very simple StrataFrame maintenance form with the business object's DeleteConcurrencyType property set to OptimisticRowVersion and the RowVersionOrTimestampColumn property set to the name of the database table's rowversion column.  All other properties in every related object remain set to StrataFrame default values.

I want to find someone willing to spend a few minutes duplicating this problem.  Unfortunately based on my previous experience on and off this forum, it will probably be very difficult to convince anyone that a bug exists in StrataFrame source code that has been in use for years.  I understand why most people will feel that way, but this bug shows up when using only unmodified StrataFrame source code and by simply trying to delete one single record at a time.  I just need someone willing to duplicate the bug using their own database application that uses a rowversion column in the backend database table.

I think I even know where in the StrataFrame source code the problem exists, but I do not have enough experience to rewrite the incorrect source code.

Any takers?

Sam Tenney