Issue 102229

Summary: Dutch version: Conditional field doesn't work when DB field name contains a dot
Product: Writer Reporter: hanssietsma <hans.sietsma>
Component: codeAssignee: AOO issues mailing list <issues>
Status: UNCONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P5 (lowest) CC: elish, issues
Version: OOO310m11Keywords: needhelp
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
testing different versions of fieldnames with spaces and dots in a conditional text none

Description hanssietsma 2009-05-25 15:24:31 UTC
Issue 98830 has been closed prematurely I am afraid (not with my consent by the
way). Using a custom field does not generate a crash anymore which is fine and
what the complaint was all about.

It would be nice however if I could actually use a customfield as a condition in
hidden text or a hidden paragraph, which was the reason I bothered to file an
issue of course. This however is still not the case. 

The form I submitted in issue 98830 still does not work properly. I did some
testing with different possibilities, including the use other fields. It appears
that using 

[Adressen.Zylt.Gebruikerdef. 1] != "V" 
'Gebruikerdef. 1' being the first customfield does noyt work as a condition.

[Adressen.Zylt.Bijnaam] != "V" 
'Bijnaam' probably being 'nickname' in English works OK. 

In both cases the field can be read and used as text in a document. But the
first case cannot be used as a condition.
Comment 1 eric.savary 2009-05-25 16:34:34 UTC
This is due to the space contained in the DB field name. And maybe also to the
"." inside of the field.

To avoid this:
Don't write: [Adressen.Zylt.Gebruikerdef. 1] != "V"
But: ['Adressen.Zylt.Gebruikerdef. 1'] != "V"

Or generally don't use DB field names using special characters and spaces.
Comment 2 eric.savary 2009-05-25 16:34:55 UTC
Closed
Comment 3 hanssietsma 2009-05-25 16:47:14 UTC
Thanks for your quick response. 
I already presumed in the first issue I filed (98830)that there should be
something at hand with using spaces or dots. 

But alas! I don't have a choice in naming the databasefield as it comes
automatically with the connection  to the Thunderbird Addressbook. The English
version does not have this problem I guess, nut the Dutch version does. 

so what to do about it?
Comment 4 eric.savary 2009-05-25 18:47:10 UTC
As I wrote, include the field reference in simple quotes and it works.

NB: Same problem with Thunderbird English - "First Name", "E-amil (2)"...
Comment 5 eric.savary 2009-05-25 18:47:29 UTC
closed
Comment 6 hanssietsma 2009-05-26 11:54:07 UTC
Thanks again for your explanation. I missed the single quotes, sorry for that.
So I tried your proposal, but I am sorry to tell it is not working. I tried all
kinds of variations, none of them seems usable as a condition (just printing the
field works OK). 

Some varaitio0ns I tried:
['Adressen.Zylt.Gebruikerdef. 1'] != "V"
'Adressen.Zylt.Gebruikerdef. 1' != "V"
[Adressen.Zylt.'Gebruikerdef. 1'] != "V"
Adressen.Zylt.'Gebruikerdef. 1' != "V"
Adressen.Zylt.[Gebruikerdef. 1] != "V"

By the way: in the helppage about 'defining conditions' is stated the following
- below the table about using fieldnames in conditions -: (translated from Dutch)

'If you use a databasefield in a condition, use the form
Databasename.Tablename.Fieldname. If one of these names contains a character
that is an operator, like the minussign (-), put he name between brackets, e.g.
Databasename.[Table-name].Fieldname. Never use spaces in fieldnames.'

Hence I tried the last cited variation, to no effect. Also I tried leaving out
the space and the dot (you never can tell what a formula parser comes up with
;-), but no result. 

Last remark: the first suggestion I was using
       [Adressen.Zylt.Gebruikerdef. 1] != "V"
was generated by OO itself, using the wizard for making a mailing. 

Thanks for your patience.
Hans Sietsma
Comment 7 eric.savary 2009-05-26 12:40:10 UTC
But it worked with a test I did using the same structure ['Database.Field.Test
1']=="AAA".
Are you sure you unchecked "View - Hidden Paragraph"? :)
Comment 8 hanssietsma 2009-05-26 13:54:28 UTC
Created attachment 62534 [details]
testing different versions of fieldnames with spaces and dots in a conditional text
Comment 9 hanssietsma 2009-05-26 13:55:30 UTC
Yes, I unchecked "View - Hidden Paragraph". 

I saw you tested with a space in the fieldname, so I tested several
possiblities, starting with a brandnew database and a new witer-doc (see
attachment).:

adressen.namen.Geslacht -> OK
adressen.namen.G 1 -> not OK
[adressen.namen.G 1] ->OK
[adressen.namen.G. 1] ->not OK
['adressen.namen.G. 1'] ->not OK

It looks like the dot in the field name is the ultimate cause of the problems.
Square brackets will do to overcome the use of a space in the fieldname, but the
dot is probably still interpreted as e separator.

Comment 10 hanssietsma 2009-08-11 22:16:49 UTC
Any progress at all??
Comment 11 michael.ruess 2009-09-16 21:01:54 UTC
i can imagine that this is the same problem as issue 72164.

MRU->OS: what do you think about this?
Comment 12 hanssietsma 2009-09-18 00:11:45 UTC
FYI: I tried using the English version of OOo lately, together with my Dutch
version of Thunderbird. It required changing the content of the condition of
course. The English version translated the addressbook fields to names without a
Dot in the fieldname. It worked OK. I reported this to the localization group,
but they did not respond.
Comment 13 michael.ruess 2011-03-17 14:43:37 UTC
Yep, problem is, that OOo uses dots to separate the parts of the DB field addresses. We once need a way to handle this.
Comment 14 Edwin Sharp 2014-03-13 18:55:08 UTC
Please specify steps to reproduce bug.
Comment 15 hanssietsma 2014-03-13 23:28:02 UTC
Oh come on gyus, please specify steps? I did that in issue 98830 and here. It is about merging a writer-document with records from the addressbook, that consists of items from the addressbook of Thunderbird. 

In the writer-document I used a conditional field to make it possible to decide during merging which text (Sir or madam) to use. This does not work out and as explained and tested below this only happens in the Dutch version (i.e. not in the English one). So, if you want to pick up this item after 5 (five!) years that's fine, bit don't ask me to explain it all over again. The information is all there, as can be seen in the work of Eric Savary.

I left OO a long time ago, partly because support isn't up to standards. Sorry to say.
Comment 16 Edwin Sharp 2014-03-14 07:49:03 UTC
Thank you for clarifying.