This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to get ActiveDirectory User Attribute mapped to an M-Files date-type Property

Hi guys,

we have a connection between our on-prem AD and our M-Files "employee" Objects. We use a legacy database connection for this.

The problem is that whereas everything works fine in general, I cannot get an AD user attribute of type string ("extensionAttribute4" in our case) mapped onto an M-Files property of type DATE ("Birthday"). I get an error message saying that conversion of datatype 'DBTYPE_WVARCHAR > DBDATE' is not supported.

Two questions on this:

1.) is it true that absolutely no conversion attempts are taking place in the background? If this is true I either have to give up or look for another AD user object attribute of a different type (which one?)

2.) if there are conversion attempts taking place and the error message is simply not precise enough, what would be the correct format for my string attribute in order for M-Files to convert it successfully? I tried "1990-03-12", "03.12.1990", "1990-12-03T00:00:00+01:00" and many others without success.

Parents Reply Children
  • Thx! Will this work even if used with the legacy database connector I described above? In other words, the conversion will take place before M-Files checks for correct data type?

  • I'm not aware of any functional or useful casts or conversions from using the AD user attributes, I bring them all in as text fields and then deal with them after and hide the text fields with metadata card. 

    so in your case I would have an mfiles text property definition "cBirthday"and then use the property calculator to run the conversion (it's like magic) into an mfiles date property definition "Birthday" and hide cBirthday with metadatacard

  • thx, works like a charm and is the way to go for my scenario! =)

    by the way, I think you don't need your second condition ("Class = Google Device"), since you already have that configured in the "Class" section above (?) Anyways, in my case using the first ("...non-empty...") condition is enough and works as intended.