How to enable roll-back on SDE transactions

[SebastianKrings]

Hello,

I used Arccatalog to transfer Data from a FileGeodatabase in my network share to an ArcSDE Database (MS SQL Server) on another machine in the same network.
While the transfer was proceeded the infrastructure brokes and the connections were lost.
After recovering the infrastructure in ArcCatalog again 80% of the datasets, featureclasses and raster datasets were stored. One was shown in ArcCatlog but it was unable to open it with error ("Failed to open dataset"). I tried to delete it but another error tells me i cannot be deleted ("Failed to delete selected  object(s)").

In the passt I still had this problem using a FileGeodatabase. Within an dataimport my computer went down. A dataset was stored and shown but I was not able to delete it.

I found threads like this one:
http://forums.esri.com/Thread.asp?c=2&f=59&t=116222

To delete rows and tables manually was the "solution" I used in the past were it happens on my own testsystem. But this is not a workaround for productive-systems.

Unfortunetely I can not find any useful information (from ESRI (documentation)) how to handle such problems (e.g. any recovery or roll-back mechanisms) and how to implement them in ArcSDE or ArcCatalog(?).
you should also consider that when the database machine went down immediately (e.g. due to a hardware-problem) those mechanisms also shall work when restarting the database.

Any help, advice, information and mybe field reports were grateful.

Thanks.

[VinceAngelo]

If you are talking about the the 'sde' user, then that is your problem right there.  The 'sde' user
should not ever own spatial data.  It exists solely for administration of the instance (and the
password to it should be tightly controlled). 

All other users (data owners or data viewers) should be granted the minimum privileges necessary
to what they need to do (I can't tell you exactly what because I don't have access to my SQL-Server
box right now, and those accesses change by release anyway).  After 23 years as a SQL-Server
administrator (and Oracle, and Informix, DB2, PostreSQL, and a bunch of very odd RDBMSes), I no
longer need to follow rote directions on configuration, but I can't explain what I'm doing either.
An administration class would be a lot more beneficial than paying to have me try to brain-dump
the jumble of cross-linked lessons learned on database security.

- V