3 Replies Latest reply on Jan 20, 2016 7:47 AM by disabled_JackRodgers

    Import 14 Test in Windows 10

      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?

        • 1. Re: Import 14 Test in Windows 10

          Further addition: I added a calc field to total the number of characters in the final text field. It was 1394 out of 1528 records implying that during the loop 132 char()s were lost. Hmm.

          There are char()s that cause a deletion and its possible that inserting one of them in the field deleted one or more previous characters.

           

          Further I expanded my test to 11,000 records to create one char for each. When I ran the script to fill the field, FileMaker crashed and it had previously. I did not a mix of language characters.

          • 2. Re: Import 14 Test in Windows 10
            user19752

            It should not crash, but the area 768...879 is COMBINING chars, need preceding char for combine with.

            Combining Diacritical Marks – Test for Unicode support in Web browsers

            • 3. Re: Import 14 Test in Windows 10

              Thanks for the URL.

               

              What's interesting 2me is that FileMaker would crash if I used set field in

              a loop with char(x) in the range of 870 to 890. I could generate the entire

              range of the characters shown in the pict and set that into a field with no

              crash but if I then clicked on the field FileMaker would crash. I could

              export that field and then import it but the one field would produce two

              fields and 5 records. Let the ASCII games begin...

               

              This raises a question since FileMaker can be installed in I think 9

              languages if any of those languages use the characters in those ranges and

              how that might affect another install in say English that opens the file?

               

              I'm using Google Translate to create labels for fields and buttons in each

              of the languages that FileMaker installs plus any other language I want to

              include. Of course the characters must fit within my buttons and labels to

              work.