The steps I went thru:-

1. Create SP in SQLDBC.
2. Checked out the SP updated it and checked back in using SQLDBC.
3. Checked out SP and made changes. Executed SQL so the SP on the server is changed but did check back in. Closed query window but did not save. SQLSDBC does not have any record of the changes in the history.
4. Outside SQLDBC I changed the SP form step 3.
5. SQLDBC recognized the server version as different. Got latest from the server. SQLDBC did not add to the history.
6. Undid the check out because I wan to keep the latest from server. SQLDBC reverted to version at step 2 with no way to get back to the version I wanted which is step 5. Net result is I lost somebody’s work.

Comments please.

USE [SYSTEM_ADMIN]

GO

/****** Object:  StoredProcedure [dbo].[SP_HistoryTest]    Script Date: 07/21/2008 10:05:50 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

ALTER PROCEDURE [dbo].[SP_HistoryTest]

AS

/*

21Jul2008 10:01 Created.

21Jul2008 10:02 Checked out and then back in.

--21Jul2008 10:03 Checked out but not back in and not saved on exit.

21Jul2008 10:05 Changed outside SQLDBC.

*/

Thanks for the detailed duplication steps.

When you perform an undo-checkout operation it will take you back to the definition you had just prior to the most recent check out.  In this case that was in step 2 because you never checked the object in at step 3.

However, the undo-checkout operation left the definition on the SQL Server untouched because I don’t want to change any code that has been changed outside of SQLDBC.  So you could perform a get latest from the server after you’ve done an undo checkout.  This would explain why you got the message “This sp has been changed outside of…” the second time round.

That said, the fact that the Get Latest didn’t add to the history is wrong so I’ll look into that.

Let me know if you feel this behavior is counter-intuitive or if you expected it to behave differently.

I am still and always have been confused about some of the processes. This is not good. Either it is counter intuitive or there are some fundamental things any user must understand and this must be highlighted.

Here are some thoughts as they come out of my head (they may be rubbish).

1. When I am working in SQLDBC, when is the object saved to the change history? I thought it was changed when I executed the code, i.e. run the alter script. Now you seem to be saying that the object is saved only when I execute save or check it in.
2. When I do get latest from server and the SQLDBC version is checked in, the server version is not changed but a new version should be added to the change history. This is fine and I assume the new version is checked in when it is added.
3. When I do get latest from server but the SQLDBC is checked out, the server version is not changed but a new version should be added to the change history. If the checked out version has been changed since it was last changed it should be automatically saved at this time because this ensures that you can always get some work back from the history should you suddenly realize you screwed up. Also you can now do a compare to see what has been happening with the various development threads.
4. Which version should rule, i.e. be the last. The one you got from the server because that is the last action you took. Should it be checked out – no following the logic from 2 and for consistency with 2.
5. What happens when you change an object in SQLDBC, i.e. run an alter, and it has been changed outside SQLDBC. That is when you give a warning the code has changed outside the project. Again, my ideal is that SQLDBC captures the changed code on the server as a new version so I can always get the code back. If this cannot be automatically then it should tell me the steps I should take to do so manually. According to the above the steps should be:-
1. Get latest from server. This will save my checked out version and create a new later version based on the server code.
2. To continue editing I will have to go back a version and edit form there. Workable but not very nice.
6. Alternatively I could overwrite the server version with mine. This would :-
1. Save a new version in the history with the get latest from server.
2. Apply my changes to the server and keep my version checked out and current. This feels a lot better. 

Comments please.

Please see inline comments, below

KePr:

1. When I am working in SQLDBC, when is the object saved to the change history? I thought it was changed when I executed the code, i.e. run the alter script. Now you seem to be saying that the object is saved only when I execute save or check it in.  An Object is saved to the change history when you check it in or execute the code.  Clicking on save will not update the change history.  In essence, whenever SQLDBC changes the code on the SQL Server itself, it should add a record to the change history.
2. When I do get latest from server and the SQLDBC version is checked in, the server version is not changed but a new version should be added to the change history. This is fine and I assume the new version is checked in when it is added. When you do a get latest a change history record should be added.  I'll make sure we investigate this.
3. When I do get latest from server but the SQLDBC is checked out, the server version is not changed but a new version should be added to the change history. If the checked out version has been changed since it was last changed it should be automatically saved at this time because this ensures that you can always get some work back from the history should you suddenly realize you screwed up. Also you can now do a compare to see what has been happening with the various development threads.  Agreed.  I think this is where the problem lies.  When you do a get latest I should be adding to the history and updating the checked out version at this point.
4. Which version should rule, i.e. be the last. The one you got from the server because that is the last action you took. Should it be checked out – no following the logic from 2 and for consistency with 2.  Agreed.
5. What happens when you change an object in SQLDBC, i.e. run an alter, and it has been changed outside SQLDBC. That is when you give a warning the code has changed outside the project. Again, my ideal is that SQLDBC captures the changed code on the server as a new version so I can always get the code back. If this cannot be automatically then it should tell me the steps I should take to do so manually. According to the above the steps should be:- Once we've implemented the changes as per item 3, above, this will be possible.
   1. Get latest from server. This will save my checked out version and create a new later version based on the server code.
   2. To continue editing I will have to go back a version and edit form there. Workable but not very nice.
6. Alternatively I could overwrite the server version with mine. This would :- Makes sense, we'll implement this.
   1. Save a new version in the history with the get latest from server.
   2. Apply my changes to the server and keep my version checked out and current. This feels a lot better. 

All these changes have been implemented.  Let me know if you want to test a build containing these changes.

Here's a quick summary:

1. When performing a get latest, history is always recorded now regardless of whether the object is checked out or not.
2. Additionally, if the object is checked out, we now add the current version to the history prior to getting the latest from the server.
3. Also, when getting latest, the checked out definition is updated – defining a new starting point (or check point).
4. If you choose overwrite , we first add the server version to the history.