Hi there,
just trying to follow your methods in the docs....
the only way that i can find to clone the database is using the 'save a copy as...' menu item on the file menu. This gives me options to either Clone (no records), copy of current file, or compacted copy.
The compacted copy i can see is not relevant. the clone gives me a database shell it appears, and the save a copy as seems to copy everything. records, graphics and all.

Hi Adrian,

You'll want the clone option. This erases all data in the solution so you'll do two things after creating your clone:

1. You'll get to the About tab (probably in layout mode since all the solution's graphics will be gone), reenter browse mode, and shift-click on the "reset" button in the lower right of the About tab. Select "All" as your reset option.

2. Then, you'll want to import the single record of the interface table in from the uncloned copy of your file. You'll want to make a temporary layout based on the interface table in your new file to facilitate this and begin your import from that layout.

By the way, can you let me know why you need to use the date formats natively? We've tried to make sure all the dates behave well without the need to clone the file: can you let me know if we've missed something?

Thanks.

John-

I agree with you. Dates should not be primarily stored in Filemaker as text, for lots of reasons, especially the trouble with calculating durations between dates. I sometimes create a calculation field that produces a text format date from a date field, but this is redundant, slows down the entry, and usually is not necessary, since FileMaker handles date format conversions internally. If for some reason FileMaker date format is unacceptable, for example the system is a front end to an SQL data store, then an appropriate numeric date format, like Julian Date or Modified Julian Date is used. These are also stored calcs, numeric, not a primary data entry field.

I usually set the Use System Format to enabled when the application launches to make the (numerically stored) date format display in the end-user locale format.

Time data is another matter. On the recent international solution I developed, we represented time from the vantage point of the server, which was set to UTC (Coordinated Universal Time), so that a transaction begun at the same instant in France would not be represented as being 6 hours before a similar transaction done in New York.

Hi John, thanks for your reply.
with regards to part 1. I'm fine with that.

part 2 i think i'll be ok for that too, although whilst playing last night i had trouble importing due to all the target fields being greyed out. I was using an account will full access, so if you have any clues for me...

with regards to your last comment, as i'm sure you know most of the rest of the world uses the european date format, and all other software works with that format. To have one piece of software that doesn't is causing us problems in that we don't always remember to switch to system date format. For a calendaring program, this seems to me to be a fundamental floor. At the very least there might be an alternative download for people that use the european date format if switching to use this format natively is such a chore.

@ tgantos...
is that relevant to my question?

I completely agree. I guess I was asking if there were places where the dates look out of place once you have switched to system date formats. You can add "Use System Formats [On]" to the opening script so that you don't have to mess with it each time. This has generally been all our customers outside the US have needed.

(I can't believe it isn't in there by default-- it is in all our other versions-- but it seems to have been deleted in the current version. I'll be adding it back right now.)

As for the container field import, your target fields shouldn't be grey providing you're in with Full Access and on a layout based on the interface table occurrence.

The dates in SeedCode Calendar seem to all use the FM internal date format. I haven't checked every date field on every layout, but if perhaps some of those are set to display in a non-system format, those probably should be changed, eh?

http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html

<img src="http://www.iso.org/iso/en/commcentre/isocafe/cartoons/date.jpg"> </img>

ISO 8601 date format avoids the potential confusion inherent in US MM-DD-YY and European DD-MM-YY as well as Japanese YY-MM-DD formats. The disadvantage is it does make the date field longer, and people may have difficulty adjusting to it, I believe that it is less user-friendy than my personal favorite of 2 May 2007, but that format does not translate well regionally. Example June and July in French start with the same first three letters, so then it gets REALLY long.

Personally I like to represent a date as 2 May 2007. If I write a letter that is what I use to avoid international confusion. I also think it looks nicer than 2007-05-02.

In FileMaker development work with International usage, I usually go with Set System Format[ON] in the opening script. John seems to do this too but in my developer version it is missing. Curious.

I usually format my date fields by letting the system format preference take over, except when showing week number or day number of year, etc.

great, thanks....the "Use System Formats [On]" in the opening script is the solution that i'm looking for. I don't believe that this causes any dates to display unusually, as with the other chap, i haven't been through every layout but i haven't noticed any bad ones thus far.
cheers

one last thing on this topic, i think this solution should be in the docs as the first method rather than the more drawn out cloning method, at least on your website.

Indeed. It normally isn't an issue as most versions have the Formats On step in the opening script. Thanks again.