Unable to Save Edits - failure when flushing edits to database

Error Message

When editors go to save their edit session, the operation fails with the following errors:

"Unable to save edits"

and

"Unable to save edits because of failure when flushing edits to the database".

Cause

1. The length of values in a DATE or NUMBER field may be too long.

In the case of an Oracle database, the verbose sde error log records:

db_sda_execute_stmt::OCIStmtExecute (1483).
[08/09/2006 09:42:54;SdeId=17487;Client=arcfm1] DB_execute_insert_table OCI Execute Error (1483).

Details on the cause:

ORA-01483: invalid length for DATE or NUMBER bind variable.
Cause: A bind variable of type DATE or NUMBER is too long.
Action: Consult your manual for the maximum allowable length.

2. There have been cases where custom tools (ArcObjects, ArcFM) that automatically populate fields when the user saves their edits have caused this error to occur.

3. If using Oracle 10g R1, this may be an Oracle bug that was resolved in release Oracle 10.1.0.5.

4. There may be insufficient space to save the edits.

Solution or Workaround

1. To narrow down where this issue occurs, check the following details:
   
   a) Check the values and field definitions for DATE or NUMBER fields that are being edited before the error occurs. If there are any custom tools or custom code updating DATE or NUMBER fields, check with the developer of the custom tools to check the maximum allowable length of values that are being inserted.
   
   b) If the user does a smaller number of edits between saves, and the error happens less often, check the available hard drive space/tablespace and increase the maximum number of concurrent open cursors by adjusting the Oracle initialization parameter open_cursors. The parameter's default value is 300; increase the number of available cursors to 3000. Test if this makes any difference.
   
   c) Check to see if the problem with saving edits only happens with one particular feature class, in only the geometric network, or with only one particular version. Check if it happens only on one client machine, with one editor, or one sde service.
   
   d) Check the workflow. Are multiple editors editing the same version at the same time and saving edits at the same time? When each editor edits in a separate version, does the error still occur?
   
   e) Check if there are table or state locks that may be interfering with saving edits by running the following command:
   
   sdemon -o info -I locks
   
   sdemon -o info -I users
   
   If other users are reconciling the version being edited, they will require an exclusive lock on the current version and target version. After all users have disconnected, restart the ArcSDE service to make sure all locks were released.
   
   f) Edit as the data owner and check if the error occurs. For editors that are not the data owner, do they have 'Select, Insert, Update, Delete' permissions on the feature classes in the geometric network?
   
   g) When contacting ESRI Technical Support, provide the exact steps and tools the editor is using to reproduce the problem. Are there any custom tools being used when the error occurs? Is it reproducible every time?
   
   h) Collect additional logs that record when this issue is occurring.
   
   Obtain SDE Verbose Logs:
   
   1. Shut down the SDE service.
   2. Open the dbinit.sde file located in %SDEHOME%\etc with Notepad.
   3. Add the following line to the bottom of the file:
   
   set sdeverbose=1
   
   4. Rename (or delete) the sde.errlog and giomgr.log files that are located in %SDEHOME\etc.
   5. Restart the service, reproduce the error, and either shut down the service or make a copy of the log file immediately after reproducing the error.
   6. Provide ESRI Technical Support a copy of the log file.
   
   Ideally, only one user that is getting the error should be connected while the error logs are being generated. If more than one user is connected, a lot of extraneous information will be included in the logs.
   
   SDE verbose should be disabled after the error logs are made, since it continuously puts large amounts of information in the logs, and it does not work if SDEINTERCEPT is run concurrently. SDE verbose can be disabled by removing the line and restarting the service.
   
   Getting SDE client Intercept logs:
   
   1. Shut down the SDE service.
   
   2. In the O/S Environment Variables (for example: right-click My Computer > Advanced TAB > Environment Variables), create two system variables as such:
   Variable name:SDEINTERCEPT
   Variable value:crwTf
   
   Variable name:SDEINTERCEPTLOC
   Variable value:c:\temp\client_intercept
   
   When intercept is enabled, a new file is created and written to each time an application connects to the ArcSDE service. ArcSDE generates a file name from the prefix provided by appending a numeric extension that begins at .001 and that increments sequentially for each new file created. In the example, the provided prefix is sde_client.
   
   3. Restart the service, reproduce the error, and either shut down the service or make a copy of the log files immediately after reproducing the error.
   4. Provide ESRI Technical Support a copy of the sdeintercept log file.
   
   To stop intercepting ArcSDE server network broadcasts, shut down the ArcSDE service and either comment out the variables by preceding the entry in the dbinit.sde file with the pound sign character '#', or delete them from the file before restarting the ArcSDE service.
   
   Getting an Oracle Trace:
   
   Ask the DBA to get a 'database trace' for the time when the error occurred. Use the following logon trigger to capture a trace of only the connection:
   
   CREATE OR REPLACE TRIGGER "SYS"."LOGON_TRIGGER" AFTER
   LOGON ON DATABASE begin
   if user like 'NameHere' then
   execute immediate 'alter session set tracefile_identifier = ''on_logon''';
   execute immediate 'alter session set events ''10046 trace name context forever, level 12''' ;
   end if;
   end;
   
   Check what the Oracle database records during a time that the error occurs. Based on the reported errors, take the appropriate action to resolve it.