Problem when doing confirming import after export
We are exporting employeeStartDate from FIM to a another SQL server database that we use for backup of all our attributes. The export is working without problems but when doing a confirming import we get the following error:
exported-change-not-reimported
I think I know why this is happening:
The value being exported is:
2001-01-31 00:00:00.000
The value being imported is:
2001-01-31 00:00:00
As you can see there is a difference (.000). However what I don't understand is why the imported value does not contain the milliseconds (.000). When I check the data in the database after the export it is 2001-01-31 00:00:00.000 so why is FIM scipping the
milliseconds (.000) when running the import?
Regards
Zid
January 17th, 2011 9:14am
I do have a SQL table with a datetime field (without millisecinds) and as a workaround I do have a MV rules extention that just adds .000 to the imported value. and export to FIM works without problems.
You do have a reverse scenario, so I would suggest to cut the last 4 characters, or everything right to the dot, or use parsedate().ToString() and so on...
search this forum - this issue (or feature?) was already mentioned here.
Free Windows Admin Tool Kit Click here and download it now
January 17th, 2011 2:04pm
Thanks for your reply. Your suggestion involves custom code from what I can understand. Is it possible to do what you are suggesting without custom code?
Regards
Zid
January 19th, 2011 1:44am
that's easy. you don't need any code. as Metaverse doesn't support datetime attributes and you store all dates as strings -
on the FIM portal in the SQL inbound sync rule flow EmployeeStartDate + ".000" => employeeStartDate
that's all.
Free Windows Admin Tool Kit Click here and download it now
January 19th, 2011 2:06am
Thanks! That seemed to do the trick.
Regards
Zid
January 24th, 2011 3:02am
I've handled this problem in the past by storing timestamp fields as a FILETIME (e.g. number) so that you don't have to worry about data fidelity when you're casting strings around.My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com
Free Windows Admin Tool Kit Click here and download it now
January 24th, 2011 4:37pm
I've handled this problem in the past by storing timestamp fields as a FILETIME (e.g. number) so that you don't have to worry about data fidelity when you're casting strings around.My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com
January 24th, 2011 4:37pm
I've handled this problem in the past by storing timestamp fields as a FILETIME (e.g. number) so that you don't have to worry about data fidelity when you're casting strings around.My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com
Free Windows Admin Tool Kit Click here and download it now
January 24th, 2011 4:37pm