Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 7 Jahren, 6 Monaten
Letzter Beitrag:
vor 5 Jahren, 2 Monaten
Beteiligte Autoren:
Igor Pobi, GuenterP, Jimbo, Fabrice Harari

[Windev 15] Unicode and Composite keys

Startbeitrag von Igor Pobi am 04.01.2011 04:43

Hello !

1. Why is not possible use Unicode item with composite key on Hyper file ?
Any alternative for composite keys ?

2. Why query designer try to create composite key (when suggested optimization) on this Unicode items ? Of course, create is not possible and query designer suggested and try this again and again ???

Thanks !


Hi, I'm never using composite keys - I compose string fields (keys) with the required information instead.

- First advantage is that links between files using these 'composite keys' are working like a charm.

- Second advantage is that extraction of information from those keys is quite easy.

- Third advantage is avoidance of duplicate data (aka redundant data) within the file. Composite keys as they are designed in Wx-products, force you to have the same information twice in a file! Composed string keys allow for having the same information only once in the file - because you can extract data without hassles.

'Composition' on insert / modification is done using triggers, so you don't have to take care of it all of the time. Though I do not use queries a lot, I suspect that you could use Middle(..) or e.g. StringVar[[5, 17]] (see: http://doc.windev.com/en-US/?1512001 ) to extract any part of such a key easily.

I'd like to see the following in a WinDev analysis file:

StringA1 First field 10 bytes .. 1 - 10
StringB1 Second field ... 15 bytes .. 11 - 25
StringC1 Third field .. 5 bytes .. 36 - 40

KeyA = 11 - 25
KeyB = 1 - 40

Currently, WinDev keys are bound to fields. In this example we'd have to pull out StringB1 and define a second field StringB2 with it - again, here we're forced to have redundant data within the same file.

Kind regards,

von Jimbo - am 04.01.2011 05:56
Hi Guenter

your method is interesting, but prevent to create a key on the second or 3rd part of your string.. It also prevents to create a second composite key based on some of the same fields (either with other fields or the same ones in a different order)

Your method also prevent direct link (file to screen) for all the fields composing your composite key

Today, as the size of hard drive is really not a problem anymore, I find your method quite limiting for little advantage... Just my opinion, of course :-)

About unicode in keys, I THINK it's something they added in 16... And why is the optimizer proposing it when it's not possible? I would say because it doesn't check for unicode before proposing..BUG...BUG.....

Best regards

von Fabrice Harari - am 04.01.2011 10:50
Hello !

No, composite key with unicode items not supported in Windev 16 :(

von Igor Pobi - am 05.08.2011 13:28
Igor Pobi
Hello !

No, composite key with unicode items not supported in Windev 16 :(

Hello !

From WinDev 17, composite key with unicode items is supported !
But ... how Windev 15 and Windev 16 reads HyperFile with composite unicode items ?
HyperFile is compatible from WinDev 7.5 correct ?

von Igor Pobi - am 06.05.2013 07:00
Hi Igor, best way to use composite keys is to convert all numerics to text (NumToString(..)) and build a single 'text'-key. This lets you circumvent the fact that composite keys are not usable for links in earlier Wx-versions. Such a text key is built best within a trigger on HAdd / HModify which ensures that all records contain their correct key. In your case the key is Unicode-text. Be careful with the numerics! Kind regards, Guenter

von GuenterP - am 06.05.2013 08:59
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.