andrewkw

My friend an I are working on the same database on different computers. I created the file on my Mac, and he has been adding data on his PC. Everything looks fine when he opens the file on his computer, except that many of the fields don't fit the last few items of their corresponding value lists. I don't know if this is because the field itself shrank, or because the text size increased somehow. Does anybody have any ideas/advice? This is a problem that is fixable by manually increasing the size of each affected field on his computer, but doing this every time I update the template is getting very frustrating. Thanks, Andrew PS: Everything is fine when I transfer the file to another Mac.

Thanks so much! That seems to have done the trick. I also figured out that if you set the date fields to display as simple edit boxes rather than calendars, FMTouch gives the option of selecting a year--thus solving the original problem. Still, it's great to know how to do this. Thanks so much for being patient and spelling it out...I'm relatively new to all this.

Again, thanks so much for your help. Unless I'm doing something wrong, following the 2 steps you listed does not work. To be clear, I changed my computer's settings to DD/MM/YYYY. Next, I saved a copy of the database. Finally, I opened the new copy and selected "always use file's saved settings." I went to a field formatted as a date and set to display an edit box. When I enter "25/12/2009," I get the error message that it needs to be entered in MM/DD/YYYY. If I enter this before changing the file options, there's no error message, but the display changes when I change my computer settings back. Is this process what you're thinking of when you say "cloning" or "native format"?

To be clear, the information is being transcribed from a paper record where the format is always DD/MM/YYYY. The electronic database will be used by 2 computers (including mine) and an iTouch, all of which have the American setting MM/DD/YYYY. So it's not that the user's computer format is necessarily different...it's the format of the data in general. If I tell the file to read from the system settings of the computer, it would always read the wrong format. I don't want to have to ask the other person to change their date formatting indefinitely. If there isn't a way around this, I guess we just have to risk some mistakes, but I thought it couldn't hurt to ask. I can also just take the time to make individual fields for each component of the date...but by that time FMTouch will have probably fixed the year problem.

Thanks for the advice. I'd prefer not to have to change the system settings for good, so I've been playing around with this a little bit. Also, the file may eventually be used on other computers, so it wouldn't be great to have to go through and adjust everyone's settings before being able to use it properly. Simply put, it looks like working through the File Options should do the trick if I turn off the custom date formatting. When I choose system settings, the field listens to the format I have saved for the OS (but this would require permanently changing my settings). When I tell it to listen to the file settings, however, it ALWAYS makes me enter it as MM/DD/YYYY (even when custom formatting is back on). I've tried cloning (save a copy as?) the file, but this doesn't seem to make a difference in terms of the settings. Is there somewhere else I should be looking to find out where the File Options menu is finding the "file's saved settings"?

I'm working on a file to be used with FMTouch on an iTouch. Since this app doesn't effectively let you choose a year when entering a date field that's set up as a calendar, I need to set it up as a regular text edit field. This is all fine so far, but I also need to format the date as DD/MM/YYYY. I can do this manually under Format-->Date, but the program still only allows me to enter the date as MM/DD/YY. If I try to put in 23/12/2003, for example, I get an error message. If I enter 12/23/2003, it accepts and displays it as 23/12/2003. This would still be OK, but I want to avoid confusion about entering values like 4/3/2003. If someone mistakenly enters March 4 as this (DD/MM), it will accept the value and display it as 3/4/2003, or April 3. The database will be used in a country where DD/MM/YYYY is standard, so I'd prefer to only deal with that format. Thoughts?