SQL queries after migration

[DaleSpies]

Hello All,

I'm not a SQL guru so sorry if this is a dumb questions. I am trying to pull the amount of data in MB and number of items archived between specific dates. Unfortunately, it looks like migrations and whatnot is affecting our ability to do this. I run the following but it show the migration date as the date most of the data was archived.

SELECT COUNT(*) AS 'Number of Items', MIN(ArchivedDate) as 'Date From', MAX (ArchivedDate) AS 'Date to', SUM(ItemSize)/1024 AS 'Saveset Size (MB)', SUM(OriginalSize)/1024/1024 AS 'Orignal Size (MB)'
FROM Saveset INNER JOIN SavesetProperty ON Saveset.SavesetIdentity = SavesetProperty.SavesetIdentity WHERE ArchivedDate >'2008-03-04 22:00'
AND ArchivedDate < '2008-03-05 6:00'

My question is this, is there any attribute that I could query against that would give me the original vault date ?

thanks,

Dale

[JesusWept3]

I am so confused you want the archiveddate, but not the archiveddate its giving you, you want another archiveddate?

[DaleSpies]

Sorry if it is confusing.

When I run my query I'm not getting the actual date it was archived. I'm getting the date the migration was done. We have had vault in place for at least 7 years, but we upgraded two years ago and all items up to the date of the migration show an archive date from the migration. My thinking was that it restamped the archive date during the migration. So what I wanted to know is there any other property that might contain the original date the item was archived.

[JesusWept3]

If you migrated like PST migrations or a third party migration utility, it will have the new Archived Dates of the items
the only other date will be idDateTime which is usually the Sent date of the email

[Liam_Finn1]

 I you do an in place upgrade the archive data is maintained but as JW2 said if you export the data and import it into the new EV environment (which is what all 3rd party tools do) then you will get new archived dates.


If you have been running the archive for 7 years and you have been archiving daily then you can assume that the idDateTime is the archived date. It may be out by one day of the archived date if your archive run starts or ends after midnight each day. If not they should match for anything archived since you started the live archiving. Any historical data archived that was created prior to the first run would be unreliable but everything else since could give you a good ballpark of when it was archived using idDateTime