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

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics