Let's say, you need to figure out why an update conflict happens, but there is no way to find that with cross-references (e.g., if doUpdate() method is called somewhere).
Normally, you could use SQL Server Management Studio, while debugging the main logic. Simply set transaction isolation level to "read uncommitted" and periodically check RecVersion field value in the "problematic" record .
However, if there is no access to the SQL Server management Studio, try the following approach:
1. Open another AX client and development workspace.
2. Create a class and add main-method to it.
3. Paste the following code to the main method:
Normally, you could use SQL Server Management Studio, while debugging the main logic. Simply set transaction isolation level to "read uncommitted" and periodically check RecVersion field value in the "problematic" record .
However, if there is no access to the SQL Server management Studio, try the following approach:
1. Open another AX client and development workspace.
2. Create a class and add main-method to it.
3. Paste the following code to the main method:
public static server void main(Args _args) { Connection connection; Statement statement; str query; Resultset resultSet; connection = new Connection(); statement = connection.createStatement(); query = "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;"; query += @"SELECT RecVersion FROM PurchLine "; query += @" WHERE PurchLine.InventTransId = N'11199055' "; query += @" AND PurchLine.dataAreaId = N'CEU' "; new SqlStatementExecutePermission(query).assert(); resultSet = statement.executeQuery(query); while (resultSet.next()) { info(resultSet.getString(1)); } CodeAccessPermission::revertAssert(); }
4. Adjust the query string as needed.
5. Go through the main logic in the debugger and periodically run this class in the second workspace, so you will know if the RecVersion value is still the same.