We have a straightforward versioning system, with just one child version off of default at the moment. We reconcile and post edits regularly (every other day at the least frequent), and compress, index, and analyze the database nightly. We had to delete the child version yesterday for some other database maintenance, and all of the edits performed in that version from the last three weeks were gone. We're pulling a copy of the backup so we can recover the edits, but I'm wondering what would cause this in the first place. My recollection is that the edits had been showing up in default; hopefully the backup doesn't prove me wrong...
The version created since then reconciles and posts correctly. I'm waiting for the backup to check to see if they had been in default previously. There were never any error messages with reconcile/post operations.
I agree with Jake that they probasbly weren't all pushed to the DEFAULT.
Before we ever delete a child version (or compress for that matter), we run a few queries to make sure things are pointing to the same version. We also use the GDBT(ools) that is old, and will not install without messing with things a bit, but it can give you a nice graphic.
For our SQL sde, the commands I run using Microsoft SQL Server Management Studio (SSMS) before and after compress:
select name, owner, version_id, state_id, parent_name, parent_owner from [<our_sde_database>].[dbo].[SDE_versions]
select * from [<our_sde_database>].[dbo].[SDE_versions]
select * from [<our_sde_database>].[dbo].[SDE_states] order by state_id
select * from [<our_sde_database>].[dbo].[sde_state_lineages] order by lineage_name, lineage_id
I do it before the compress just to see a count of the changes, etc. I do it after to make sure the state_id is the same. I do not delete a good Child unless the state_id is the same....and preferably zero. I would also do a compress after deleting the child...which should put you at zero if you weren't already.