As from which ODS are field names in a Notes document case sensitiv?

HCL Domino Domino Forum
, , ,
1

Hi there,

I got the following 2 fields in a document in a DB with ODS 52:


MassBLand and MassBland seem to be 2 different fields. How can this happen ?
Client is 12.0.2 FP5 and the Server is 14.0 FP2 HF39

Sincerly

Jochen "Joe" Herrmann

ADDENDUM:
Its not only this document there are more with the same problem with the same 2 fields.

2

Hi Joe, Are you sure that is MassBland and not MassBIand. It seems the same but the first is lowcase l and then second case is i with uppercase (I). Visual seems equal.

Yours sincerely, Roger.

3

The fields are case insensitive across all ods versions. The second L is most likely a capital i

4

Hello Rajneesh,

this was my first assumption, but , unfortunately, this is not the problem. Its in fact in both cases an "L" or a "l"

I changed the field name in the Form From MassBLand to MassBland and it still show onyl the "" value. Guess I have to delete this first field.

But the question is hopw this could happen ?

Any ideas ?

Joe

5

Is the image from a form or a view. Can you test by creating two fields on the form with the same name say TEST and Test. There can be multiple items by the same name in a document. However, in a form the name cannot be repeated even with a different case. Seems like a massive glitch.

6

The image was taken with Panagenda Properties from a document in a view

The field is first created from a JSON import with a different original field name in the Import DB.

Then the final new document in another database is created and all fields with their new names written into this new document, thgen computedWithForm and then saved.

I found more documents with the same problem and its again onyl the field massbland

Thus this problem only seems to appear with this field name ... really strange!

Joe

7

Hello Roger,

thanks for your reply.

"massbland" is written once with an "l" and the other one with a "L" and as far as I can remember are the field names not case sensitive in Notes/Domino. Thus I am wondering why this field exist 2 times as it only contains 1 value and its not an RT field. And in the form only the 1. instance "" is shown.

As the document is brand new but uses for historical reasons a computeWithForm I assume that there is something going wrong

Kind Regards

Jochen "Joe" Herrmann

8

Hi Joe,

To exclude any "GUI or representation" glitches you may want to use NotesPeek to inspect and/or txt dump the document and its fields.

Best regards,

-Niels

9

Hello Niels,

thanks for your reply.

The first image was taken from the Panagenda Properties but this one is from ScanEZ. (Attachment)

There are 2 fields with the same name only one with a "L" and one with a "l"

Kind Regards,

Joe

10

Hi Joe, I understood your issue now.

If you create a form and try creating two fields with the same name but different cases , you wont succeed across the ODS Versions. So a Form can not have two fields with the same name.

In your case your documents are being manipulated by some script.

Now if the script uses doc.replaceitemvalue("MassBland","New value"), the MassBland Item gets a new value. regardless of the case used for "MassBland")

but if your script uses appenditemvalue, the picture is different. As i wrote before , a document can contain multiple items by the same name even with the same case eg

doc.appendItemValue("MassBland","1") creates an item MassBland with value 1

doc.appendItemValue("MassBland","1") creates a new item MassBland with value 1

doc.appendItemValue("massBland","2") creates a third item massBland with value 2

As far as your Notes Form is concerned, it will use the first massbland item regardless of the case

for access via a script , you need some work around which your script is using

See the difference between appenditemvalue and replaceitemvalue below (from domino designer help)

so in effect a form cannot have two fields with same name regardless of the case. however, a document may have multiple items by the same name. You can even have MASSBLAND item 10 times in a form with full uppercase with different values.

Note: In general, ReplaceItemValue is favored over AppendItemValue. If an item of the same name already exists in a document, AppendItemValue creates a second item of the same name, and the duplicate items are not accessible except through a work-around. If you are creating a new document, AppendItemValue is safe.

Please check your code

11

Hi all,

I solved the problem !!!

For the transfer from the Import DB to Destination DB I wrote a class with a table containg the web field names , the destination field name and the field type.

For strings this command does the job:

Call destdoc.replaceitemvalue(v.destname, webdoc.Getitemvalue(v.webname) )

But the proplem was in the table:

v.webname="field_bundesland"
v.destname="MassBLand "

Can you see what happend ? Can you see the problem ?

There is a bit too much.

There is a stupid blank " " behind MassBland !

I am pretty sure that the guy in front of my keyboard caused this problem :-D

But it also means that the doc.replaceitemvalue method accepts fieldnames which end with a blank ! Dangerous !

Kind Regards
Joe

12

hi joe

"MassBland" and "MassBland " will be two different items. The replaceitemvalue as well as append item value will accept blank spaces. so replaceitemvalue("Mass Bland") creates an item by the name "Mass Bland". this will be accessible only via script and not via a form as form will not let you create a field "Mass Bland"

There is no security concern in this. it has been like this since the earliest versions

regards

13

Hello Rajneesh,

yes thats right, but I was never aware of it and a blank somewhere in the name is visible but a blank at the end of the name is another story ! Its really hard to detect.


Have changed my class now so that all entries names get automatically trimmed before stored in the table.

Kind Regards

Joe