I wondered what was happening. I've also noticed this, but figured I was doing something wrong. I made a demo using SF sample data and indeed, it is reproducible.

In BusinessLayer.Events.VB

Glad I found this post, I have been trying to figure out why a weekly import routine quit working correctly and thought I was crazy cause the BO was starting on the second record. Thanks for finding this one it saved me some time trying to figure out why the record pointer was on the second record.

Ok now that I know what is happening I really urgently have to fix it as it is holding up a weekly data import, I really don't want to have to go through all the fill methods and make sure the record is in the correct position.

Any ideas on what is causiing this and what needs to be changed to fix it?

Any ideas?

Is there a difference between the source posted in the user accounts section and the latest build that is posted here on the forums?

I needed to get this working ASAP so i just obama rigged my import code to check to make sure it was on the first record after filling , after that i decided to see why it was doing that and to make sure I had the latest source I downloaded it and rebuilt it on my system and then issue was gone, I did not change anything just downloaded and rebuilt it in debug so i could step though. I could be going crazy it has been a long day but I am thinking that is what happened. I'm going to leave well enough alone and get while the getting is good but figured id post this just in case im not crazy.

Well as I thought that was to good to be true I guess I must have mismatched version's or something because the Strataframe addin would not load this morning, I reinstalled back to the latest beta version and that fixed the problem with the add-in but I still have the issue with the record pointer being in the wrong place.

Just curious if the SF guys are looking into this?

Fixed...creating a new build as we speak and will post it within the next 30 minutes or so.  This problem was actually introduced on April 28, 2008 (during the 1.6.6 beta) in response to fixing another issue.  If you look at the SF source code, the _CurrentRowIndex is not a private but a property that was changed from a private to a property when the Shared DataTable was introduced to the framework.  Per some other threads and forum posts, there were certain conditions where the _CurrentRowIndex would be set to an illegal value on a Save or Undo which would produce an error (when records actually existed within the BO).  This was actually a correct change, but the framework had original code which attempted to set the index back 1 and then call the Navigate(Next)...well, if the _CurrentRowIndex was set to an illegal value, the index would not move...thus when the next was called, the record would move forward since the _CurrentRowIndex didn't actually change.  This has been changed by logically raising the Navigated event and refreshing the bound controls versus forcing a navigate in all areas that had this logic...in short, it was an easy and quick fix and I will let you know when we have the new update posted (should be just a few minutes).

Here is the fix: http://forum.strataframe.net/FindPost18786.aspx

Thank's a bunch Trent