dbs crash on mac but open on pc; others vice versa

[cdefeciani]

can someone please suggest a solution. I have some databases that crash immediately after putting in the password. the odd thing is, the ones that crash on the Mac host open just find on the Windows host, and the ones that crash on the Windows host, open just fine on the Mac host. I need to host all the databases on the same box and have already tried recovering, cloning w/no records and importing, etc. all to no avail.

I had read somewhere that the crashing might be due to a corrupt layout and that I should delete the layout, but how can I do this if I can even open the db on the box that it crashes on?

also - it is true that I will have to run 2 boxes in order to host DBs on a server, yet also serve them up via the web? FileMaker has been reallly disappointing since the last few releases and I have been using it since the days of FM2

thanks for any and all assistance

[cjaeger]

illegal characters in (related) filenames?

("/"or ":"on the mac) ("" on windows)?

use of corrupt fonts?

[cdefeciani]

thanks, Christian. I do not have any illegal characters in any of the database file names.

Can you suggest a good way to methodically check both systems for corrupt fonts?

[falkaholic]

I just dealt with a problem similar to this today. I had a field that did some strange math with sub summaries and some multi key self relationship. FM 5.5 for OSX didn't seem to like it. It crashed the first time then would just freeze every time after that. I had to perform a script from an external file to make it switch to a different layout that didn't contain the evil field.

[jonesy17]

cdefeciani said:

also - it is true that I will have to run 2 boxes in order to host DBs on a server, yet also serve them up via the web?

My experience over the last few months is yes, you will need two boxes: one to run FileMaker Server to host the dbs; and a second to run FileMaker Pro Unlimited to server them out to the Web. I tried running both on the same machine (on PCs with Windows 2000 and NT 4, and on Macs with OS 9.2.2 and OS X 10.2.8) and in every case the FMP Unlimited was slow as molasses in winter with the Web connectivity. The minute I separated the two apps to two different PCs (FM Server on a NT 4 PC and FMP Unlimited on a Windows 2000 Pro PC) every sped right up.

[cdefeciani]

OK I used FontDoctor to check for corrupt fonts on bot the Mac and Windows machines - it found nothing wrong.

I also made sure that the databases used a font that was common to both Mac & Win systems (Arial)

I hid the filename extension on the Mac 0SX so that there would not be any "." in the file name.

I also switched all the DB layouts to open with a different layout (one that only contained fields and tex - no images, etc

Still no luck! Mac FMPro continues to crash when I try to open the DBs that are currently running fine on a Win system and Win system crashes when I try to opwn the DBs that are currently running fine on a Mac system.

Can anyone suggest any other solution? I am fairly desperate at this point and absolutely must get all the DBs hosted on 1 box.

Thanks again for any and all suggestions!

[Vaughan]

Drastic measures time:

First make sure *all* clients and servers are running the latest patch levels of FMP and FMS. Go to the FMI web site and check. Test the system.

If there are still problems, close FMS and open the files in FMP. Make a compressed copy of each file. Move the originals to a safe place, put the copies on the server and and host them, see if it makes a difference.

Still no good? Go to the oldest backup you have a see if it exhibits the problem. If not, work your way through the backups until you find the first one that does. Then work out what the difference is (may have been a layout added or something). See if you can fix it.

If there is no difference between the good and bad files, perform a Recover on the bad files, clone the good ones, then import the recovered data into the clones. DO NOT USE THE RECOVERED FILES. Use recovered data in known-to-be-good clones. Remember to be careful when importing to preserve all the existing auto-entered data, and to reset auto-entered serial numbers in all the cloned files after the import is complete. Go slowly and methodically, it's not a trivial process.

That should keep you busy for a couple of days. Might even fix the problem too.

[cdefeciani]

Before I go through all that which indeed will be very time consuming (as I manage over 200 desktop computers, a few servers, misc. peripherals and our web site), I noticed there was a FM "crash log" in my Library directory (I am using Mac OS 10.2.8).

Since I am not a developer/programmer, can you or anyone interpret the crash log data for me? Perhaps this will provide a more immediate solution. I've pasted the log here (again, many thanks):

Date/Time: 2004-02-10 15:00:53 -0500

OS Version: 10.2.8 (Build 6R73)

Host: gc229-mac.chem.brown.edu

Command: FileMaker Pro

PID: 1770

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_INVALID_ADDRESS (0x0001) at 0x20000000

Thread 0 Crashed:

#0 0x00427b6c in PgSetupSetup__FP9TFileStat

#1 0x002d9b88 in InitState__FP9TFileStatP12DocPrefsTypeP6TStateUc

#2 0x002d6e14 in Begin__15DOC_Open_EnvRecFPC15XPascalStr_<31>PUc

#3 0x002d71c8 in DOC_Open__15DOC_Open_EnvRecFPP9TFileStatP9TFileStatP4FMFSUcPC1

#4 0x002d72c0 in DOC_Open__FPP9TFileStatP9TFileStatP4FMFSUcPC15XPascalStr_<31>U

#5 0x002da820 in DOC_OpenDeluxe__FP4FMFSP4FMFSUcPC15XPascalStr_<31>Ps

#6 0x002dace0 in DOC_GetFile__FUc

#7 0x002d8d98 in DoModal__13CTemplateDlogFv

#8 0x002d8e84 in DOC_TemplateDialog__Fi

#9 0x002dad74 in DOC_OpenNewFile__Fv

#10 0x00217ad4 in AE_HandleReqdEvent__25AE_HandleReqdEvent_EnvRecFP6AEDesc

#11 0x00217d0c in AE_HandleReqdEvent

#12 0x91b56570 in _Z20aeDispatchAppleEventPK6AEDescPS_mPh

#13 0x91b590cc in _Z25dispatchEventAndSendReplyPK6AEDescPS_

#14 0x91b56478 in aeProcessAppleEvent

#15 0x96a83778 in AEProcessAppleEvent

#16 0x0031e138 in InitInstance__9CFMProAppFv

#17 0x00a5a070 in 0xa5a070

#18 0x0031d740 in main

Thread 1:

#0 0x9000508c in syscall

#1 0x90515d0c in BSD_waitevent

#2 0x905156dc in CarbonSelectThreadFunc

#3 0x90020c28 in _pthread_body

Thread 2:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9051dbf0 in CarbonOperationThreadFunc

#3 0x90020c28 in _pthread_body

Thread 3:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x905259e0 in CarbonInetOperThreadFunc

#3 0x90020c28 in _pthread_body

Thread 4:

#0 0x90042588 in semaphore_timedwait_signal_trap

#1 0x9003e7b4 in _pthread_cond_wait

#2 0x9022ffa4 in MPWaitOnQueue

#3 0x90736fc4 in _ZN13TNodeSyncTask12SyncTaskProcEPv

#4 0x9025e364 in PrivateMPEntryPoint

#5 0x90020c28 in _pthread_body

Thread 5:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9023317c in TSWaitOnSemaphoreCommon

#3 0x9024890c in _Z15AsyncFileThreadPv

#4 0x90020c28 in _pthread_body

PPC Thread State:

srr0: 0x00427b6c srr1: 0x0200f030 vrsave: 0x00000000

xer: 0x00000000 lr: 0x00427b64 ctr: 0x9005e1f8 mq: 0x00000000

r0: 0x00427b64 r1: 0xbfffdca0 r2: 0x00b58000 r3: 0xbfffdce4

r4: 0x20000000 r5: 0xbfffdcfc r6: 0xbfffdce4 r7: 0xbfffdd20

r8: 0x00046010 r9: 0xa0001048 r10: 0x00046290 r11: 0xa00044b0

r12: 0x9005e1f8 r13: 0x0267f000 r14: 0x00bdb7ea r15: 0x00000000

r16: 0xbfffe620 r17: 0x713fa02d r18: 0x00bdba1c r19: 0x05d658a0

r20: 0x00bdb9b4 r21: 0x00bdb58c r22: 0x00bdb954 r23: 0x00bdb904

r24: 0xffffffff r25: 0x00000001 r26: 0x00bdb91c r27: 0x0267f000

r28: 0xbfffdf3c r29: 0xbfffdf74 r30: 0x00bdba34 r31: 0x0267f000