OK, I now think I have gotten one step further with this. It appears the order of commands described in the Help topic "Editing versioned data in SQL Server using SQL" is incorrect, or that the ArcSDE stored procedure "SDE_getglobals" falsely doesn't allow you to set the current version when not in edit mode (at least in SQL Server, I don't know in other RDBMSs).In addition, it appears any set version, only applies to the current active Transact SQL window, meaning you can't use it to change the way the view appears to the world outside SQL Server Management Studio (e.g. in Quantum GIS). Other applications accessing the Versioned View will only see the DEFAULT. Probably not entirely illogical, as setting the version as a kind of global for the entire database, would cause all users connected to the same Versioned Views to see the same version, and get confronted with subsequent changes. It needs to be user tied, or in this case limited to the context of the Transact SQL window.It essentially means that edits against a specific version of a Versioned View is only supported straight in the Transact SQL command window, otherwise the ArcSDE C/Java API or ArcObjects is required, like for example the FDO Provider for ArcSDE in AutoCAD Map 3D does (uses C API) that does allow version switching on a user connection basis.According to the Help the order of the commands is:1) Open a Transact-SQL query window and execute the create_version procedure to create a named version in which to perform your edits.EXEC sde.create_version 'sde.DEFAULT', 'myedits12111', 1, 2, 'version for my mv edits';
2) Set the version for the edit session to the child version you just created.EXEC sde.set_current_version 'myedits12111';
3) Start an edit session by executing the edit_version stored procedure and specifying 1.EXEC sde.edit_version 'myedits12111', 1;
However, I discovered the "sde.setcurrent_version" command fails and returns -1 for the version_id if NOT IN EDIT MODE already, even though the command is reported back as having run successfully.This means you must run the text line:EXEC sde.edit_version 'myedits12111', 1;
before running:EXEC sde.set_current_version 'myedits12111';
E.g. if I enter (please note my ArcSDE is "dbo" owned, replace with "sde" if SDE owned):EXEC MyDatabaseName.dbo.set_current_version 'MyUser.MyVersionName'
than this fails...If I enter:EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 1
EXEC MyDatabaseName.dbo.set_current_version 'MyUser.MyVersionName'
EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 2
with a start and end of an edit session, the command does run successfully. How do I know this? Well, first I entered some debugging code in the stored procedures for the "set_current_version" and "SDE_set_globals" and "SDE_get_globals". The results show the version_id is returned as a false -1 if not in edit mode, but the correct version_id for the "MyUser.MyVersionName" version if IN edit mode when setting the version.In addition, I added a SELECT statement against the Versioned View in the same Transact SQL window, and the result showed the correct, NON-Default, version data with all the edits I did.E.g.:EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 1
EXEC MyDatabaseName.dbo.set_current_version 'MyUser.MyVersionName'
EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 2
SELECT * FROM MyDatabaseName.MyUser.MyDatasetName_VW
does show the proper Spatial Result of the Versioned View in SQL Server Management Studio.
