1. Some of the questions above
Using IBObjects my transaction handling is a bit more convoluted than “just one transaction”. For test projects, however, i only place transaction objects if i am testing multiple transaction handling. So no extra transactions besides the one(s) FireDAC will auto-create.
In IBObjects the connection setting of “CharSet” is only used when creating databases. When opening a database, this information is present and read from the DB. I have no idea about FireDAC but of course i have looked through every single property of every component.
You have pointed me at CodeSite previously. However, i rather trace along, it is as complicated as trying to locate inconsistencies in huge logs that i am not familiar with. What would be better using logging is that the Alexandria debugger chokes a lot of the times. If you have breakpoints and just skipped 121 hits to get to the right instance, it’s enormously frustrating…
To download sample data and set it up i need to check everything around that data too, so i do not feel i will save any time.
2. Problem solved for me
After tracing and switching FireDAC/IBObjects/FireDAC i have found the offending line. In
TrbCustomWordsFireDACLink.GotoWord at the 16th line (@626) there is this:
Params.DataType := ftString; // D21 wants to know the DataType
in a couple of other places, the rbWord field’s DataType is overwritten, but with ftWideString. When tracing to the next line i could see in the debugger that the word had been “normalized” after that assignment.
This was logical because i could see (after catching the DB exception, and logging the words) that some words where only missing while some had MORE words in the rbBatchAdd:ed list. That rbBatchAdd would find more words than rbMake was a conundrum.
So i changed to
Params.DataType := ftWideString; // D21 wants to know the DataType
and now i do not get any duplicate index error when running batchAdd!
Also running make for location 1-1000 gives axactly the same checksums as running rmMake on 1-899 and rbBatchAdd on 900-1000. Finally!
So to answer the last question, no i do not think you would have been able to reproduce the error with other data.
In order to really pin down what is going on here one would need FireDAC sources and/or acceptable documentation (like the docwiki). I would suspect a bug in FireDAC, perhaps something to do with the client library.
The offending Characters did not offend at every character position, some only first and some only in the middle. I do not have time to do speculate, but it smells charset conversion. Here are some of the erroneously “normalized” words:
ČLANOVI, POVEĆALI, IZMEĐU, POMOĆ, ODREĐENIH, ŠESTOMESEČNOM