String attribute values with trailing spaces are trimmed

Why is v3.0.0 being used?

Please see:
http://msdn.microsoft.com/en-us/library/ms187403.aspx

Could you please check the ANSI_PADDING setting for the database.

I would like to rule out that the database is at fault.

Thanks

Version 3.0.0 is being used because that's what was already installed. I can upgrade to 3.0.5 some time today if that will fix the problem? Will check the ANSI_PADDING setting first though.

I would prefer v3.0.0 retired and v3.0.5 used everywhere possible. My question wasn't related to the actual issue and I doubt it will have any effect, but v3.0.5 has significant performance enhancements and bug fixes.

OK - I found that the "ANSI Padding Enabled" setting for the Identity Broker SQL2005 db was indeed set to FALSE. I changed this to TRUE (and set the recovery model for the db from FULL to SIMPLE while I was there to avoid disk bloat in DEV!), however this made no difference to the result. The column dbo.EntityValue.StringValue is of type nvarchar(450), as opposed to varchar, and I can't work out if the text in the article's table entry for "varchar or varbinary" implies both data types or not (http://msdn.microsoft.com/en-us/library/ms187403.aspx). In any case I was able to find the db value concerned and prove that in BOTH cases (on or off) the data in this column is persisted OK with a trailing space. This would appear to imply that the problem is at the adapter level wouldn't it?

Here's my proof of the database value being OK:

select ck.Caption, '#' + StringValue + '#' As StringValue, ev.PartitionId
from dbo.EntityValue ev
inner join dbo.CollectionKey ck
on ck.CollectionKeyId = ev.CollectionKeyId
and ck.Caption = 'l'
where ev.EntityId = 'D95D4764-D78F-4D49-BC42-97AEE29FCF2F'

l #C1 Callam Offices, Easty Street, Woden ACT 2606; # 45F0C3AD-C072-4B89-9BD4-824DD3ABE1BF
l #C1 Callam Offices, Easty Street, Woden ACT 2606; # 0F106FE0-3488-4E72-A356-D5B4CC6E2B4D

(couldn't immediately determine which partition was relevant, but both values clearly show a trailing space)

Upgrading now to V3.0.5 and will confirm the results are the same with this version.

Your reading of the link sounds right regarding nvarchar not being affected by the setting.

Could you take a look at the UNIFYFull.txt (the LDIF file) that is somewhere in the FIM directory, and find the relevant entry.

Could you please paste the whole entry?

Thanks

Doh! Must have been too tired to think of that first!!! The following clearly shows that the adapter is doing the right thing because the trailing space is there. I guess that means the problem is either the ECMA or the ILM SDK!

dn: UID=Pat Aloisi!
objectClass: person
IdBID: d95d4764-d78f-4d49-bc42-97aee29fcf2f
l: C1 Callam Offices, Easty Street, Woden ACT 2606;
facsimileTelephoneNumber: (02) 6207 5020
personalTitle: Mr
title: SOE Developer
ou: Technology Branch
mail: Pat.Aloisi!@dev.act.gov.au
telephoneNumber: (02) 6207 5299
cn: Pat Aloisi!

I just ran a quick ILM test, creating a new Text (LDIF) MA using the above file, leaving the text file Code Page "Western European (Windows) 1252". The records were read into the CS and I was able to do a "cut-and-paste" from the console of the relevant item:

add,l,string,,"C1 Callam Offices, Easty Street, Woden ACT 2606;"

So - trailing space has been stripped.

Now editing the LDIF file and putting the string in quotes doesn't appear to be a valid LDAP concept (because the "s were imported, but it does show the space in the value in the CS:

add,l,string,,"""C1 Callam Offices, Easty Street, Woden ACT 2606; """

Am working with ILM2007 Enterprise Edition, Version 3.3.1139.2

According to the LDIF Specification items with a trailing space must be base-64 encoded.

This will have to be addressed in a future version of Identity Broker.

You will have to workaround the issue, by trimming the trailing space, or having other logic in your code.

Thanks.

Thanks Adam. I won't be changing the ILM code because that just compounds the problem, so if this arises in Production before an appropriate fix comes along, the response to the client will be to install the next release when it becomes available. In the meantime I'll change the data.

Trailing spaces are now base-64 encoded. LDIF reading into Identity Broker needs to be updated accordingly.

Fixing up remaining estimate

LDIF reader also handles base-64 values. Both writing and reading have been unit tested. Please confirm resolution when appropriate.

Closed.