Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Character byte encoding in Filemaker 6 database


This topic is 7375 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I have an odd technical question. Maybe someone knows enough about the internal process of Filemaker to be able to answer this.

I'm working with FileMaker 6 database application (of about 50 related tables) that resides on a Macintosh server. Users run the application from both Windows and Macintosh computers. I have written an Applescript that makes calls to FileMaker to read records and then writes out data to a UTF8 text file. (To keep this email short, I will simply state that I can not use the export feature for the Filemaker database to write out the data as Unicode because the relationship of the data needs to be maintained and in some conditional situations aggregated.) A concern has come up from management that if both Windows and Macintosh workstations are writing to the Filemaker database on the Mac server, that the character encoding in the Filemaker database may not be all one encoding, i.e. ISO-8859-1. There is concern that the character set being written from a Windows machine could be Win1752 and from a Mac MacRoman. Thus when records are selected, the character set will vary depending on where it was edited.

There is concern by others that if FileMaker is storing the data in multiple encodings, that Applescript won't know when it changes and thus the translation to UTF8 might not be completely accurate if it expects all characters are Mac encoded and there are some that are Windows encoded in the data fields.

I can't imagine that a server DB application would work by storing data based on the character encoding for the client machine. I am guessing that Filemaker Pro internally stores all character data in a single encoding or internal format when the database is run from a server. Could anyone confirm this for me? If I know that all the data in the database files is using the same byte codes to represent characters no matter what workstation type (Win, Mac, etc.) was used to key the data in from, that will be helpful.

If the answer is that for FileMaker 6 multiple character encoding can occur for a database accessed from different client OS machines, then I would be curious to know if Filemaker 7 with its unicode support does store all data internally in the database using a single byte encoding format.

Thanks in advance for your help.

Posted

This was an issue that affected a major project where I work, so I wound up calling Filemaker once my manager approved it. I thought I would share the answer I got. It was exactly as I would think a cross platform application would have to work:

After some researchby the Filemaker technician, I was told yes. Filemaker stores characters, for example

  • 1 month later...
Posted

actually, before FileMaker 6 XML export, I wrote a rather lengthy substitute() function to export UTF-8 from within FileMaker. Must be somewhere in Sample Files (UTF-8 export).

Then I used XML/XSL.

Nowadays, FileMaker 7 does the Job.

In all cases, Export was the same on all platforms. And believe my, I was using almost every ASCII characters from 128 to 255. The trick was to export tab-delimited , Mac character set on Windows machines. I still use that technique to output binary data from FileMaker. Still works in 7, though you cannot use ASCII 0 in calculations directly anymore. Reference a field containing it instead.

As for the data grouping: i solved that within filemaker, compiling the results into a result table (file), then used standard fileMaker export.

This topic is 7375 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.