Import 14 Test in Windows 10

Discussion created by disabled_JackRodgers on Jan 19, 2016
Latest reply on Jan 20, 2016 by disabled_JackRodgers

After stating that FileMaker doesn't care what the char() is during an import rather emphatically in the thread

Re: FM Crashes During Large Import (Over the Limit)??


I decided to test my hypothesis.


Maybe I should have done this first?


OK, here's what I did:


First I scripted a loop to fill a text field with Char(a) & Char(a+1)....char(a+1000)...

The script caused FileMaker to crash...  OOps.


So I began backtracking and found the miscreants to be char(888) and Char(889). There the crash occured.


Oddly enough if I scripted the loop to run between 800 and 890 it would not crash.


Scripting the loop to run between 870 and 890 it would crash.


Next I used my ASCII file and looped through the records set text field to textfield & characterfield. It added about 1500 sequential Char()s to the field. No problem. But when I clicked on the field, FileMaker 14 crashed. Problem.

I added a step to the script (before I could crash it) to export the field to a text file. It looks like this:

Char Test.png

As you can see there are line breaks and it appears that several languages are being used. If I used more char()s I think more language characters would appear.


When I did an open file for this text file, two fields were created and five records.


This points to the need to limit the characters in a file being imported to each language and to also clean up the various characters that might have been erroneously entered. In one instance a client had entered CNTRL+M or Command+M which produced an invisible character and did this several times until finally changing to Shift + M. The typist was a speed typist and used to not reading what she type so she didn't notice the missing capital M under a later search failed to find Margaret. I was accused of messing up as most developers are if a problem arises. Sometimes we are.


My statement was that FileMaker would not crash when importing uncleansed text and it did not. BUT it did not import the one record into one field due to the line breaks and it also interpeted the tab that was created by my loop and created two fields instead of one.


Since the new fonts (Unicode?) contain thousands of characters for various languages we can expect to encounter similar problems when importing text with mixed or different languages.


Did I mention that some characters did not show up in the fields?