I have some Dbs I've had on the web for a number of years. Completely stable under 4.1, not quite as good under 5.0 Unlimited. Just upgraded to 5.5v2 Web Companion 5.5 v4 on a dual CPU G4 running OS X 10.2.2. Some of the Dbs are local, some are opened from Server v5.5 also running on a dual G4 under OS X 10.2.2. Every few days FMU just unexpectedly quits. Just pops up a dialog box that says that, no other hints or anything else in any of the logs. Anyone have any hints?

Hmm... we were just talking about that in the MAC Hardware & Networking forum of FMForums...

CLICK HERE TO SEE POST

I haven't seen/heard anything yet as to solutions but I hear Windows has a similar quirk (except not Anatoli's systems) with gobbling CPU resources. Someone else even said FileMaker, Inc. told him his system was too powerful to run FM properly. He used a more humble system with less RAM and his problems went away.

I'm trying to use a workaround that will auto-boot our server every day in the wee hours, but we're having trouble getting even that "simple" thing to work.

I've seen other folks with the same problems on Mac OS X 10.1.2 and FMP-u. You have both Unlimited and Server, right? But it's just U that quits? Hmm... good to know, but I don't think anyone's given any good answers yet.

Here is the proof:

http://www.didi.cz/servertime.gif

We scheduled the reboot to year 2004 when we will update the HW

Yes, Server seems to run just fine, it is only FMU that quits. I have started rebooting every morning when I come in, but that is only a short term solution. It is possible that lingering corruption in the DB's is the culprit. I mention this because Server 5.5 certainly seems to be more forgiving of "bad" databases. When I upgraded to 5.5 Server & Unlimited I immediately had some crashing problems when connecting to the Server. In the past Server would not open corrupted DB's, but this copy of Server had done just that. When I identified which one and Recovered it the problem ceased. Perhaps FMU 5.5 is more forgiving as welI. I may go ahead and do a Recover on everything, but all DB'd at least appear to be fine, and I was hoping to avoid the grunt work of running Recover on dozens os DB's, then having to test everything out (sighing heavily here). Hopefully something will turn up.

Hmmm.. what the heck: I only have a couple db's so I'll try that, too. If it works, I'll post a success story here.

Thanx for the tip.

Well, after talking to FMP support they tell me I should be restarting FMU every 24 hours, 48 at the outside. Yow, ugly!!! Ceratainly makes FMU far more unattractive as a web solution, but it still is a plus for me nonetheless. I may end up goinmg back to runnning it on OS 9.2.2 so I can use the scheduled shutdown & startup in the energy saver control panel. Also I didn't have unexpected quits under Classic, although I was running FMU 5.0 insteads of 5.5. From what FMP support told me this could be a result of lingering corruption that was magnified in the conversion of the Dbs from v4 to v5. There are platform specific chunks of code in the databases, so they could run OK under one OS, but have stability problems under another. I guess I'll see, since the only other suggestion was to recreate the databases. As I have dozens of complex ones this is not a good option.

Here is cheap insurance for the future: when you have finished a solution, save a cloned (empty) copy and keep it safe.

When the files need rebuilding it's just a simple matter of importing the data from the old files into new copies of the clones.

One of my clients has FMU 6.0 with "OS X 10.1.4". It runs fine without the need for restarts.

Just an observation.

All the best.

Garry

We have 2 FMP-u servers

(1) Mac OS9.2 restarts w/Energy Saver every day

(2) Mac OS X 10.2 running FMP-u in Classic mode restarts w/cron every day.

So far #2 has worked out best for us and has the most UP time. Plus, it has the distinct advantage of being able to be rebooted via SSH from the Mac OS X command line (terminal) from a remote location. #1 will soon be abandoned and replaced with a Mac OS X machine that will run FMP-u natively in X. We're hoping that pure X will be the most stable.

We'll start using Vaughan's strategy but are a little sad (sigh) that it comes to that. "Finished" is always a relative term w/us.

Thanx for sharing, folks.

The method Vaughan describes for back-up is wise for any dbms. As an example, for mySQL the best backup method is to export the data and structures; then a restore can be done on any part of the database.

All the best.

Garry

hi,

My fmpU dies on me sometimes too (OSX.2.3). I can't figure it out since it occurs at times when the db's are doing almost nothing (just a few webusers). It certainly doesn't happen every 24 hours, but it's still annoying to turn on the panel and see the message that fmpu has quit unexpected...

Now that we're on this topic anyway, what is a 'safe' way to automate shutdown *and* launch of FMPu with an interval of lets say 5 minutes? Say, every 24 hours, just to be sure?

sorry, I just opened the link above concerning this topic, didn't know i was asking the same her

Thx

JP

On Windoze easiest is to use schedule for closing and opening FM.

I believe there is something like that in Mac OS X?

Yep I also have the same problems and I am very dissaponted, on OS9 I had a very stable server, and as soon as I entered the OSX 10.2.3 world it quits twice/four a day I also host a good number of FM db's that are accesed in several ways.. WEB, FMcompanion etc.. I created an AppleScript Script for recovering automatically from crashes that is trigered using IDOX scritpt scheduler that runs every 10min. (http://www.sophisticated.com)... there are not the answer as Filemaker still quits but at least it recovers..

Here are the scripts..

"rescuefromcrashv1"-- (this is the script that should runn with the idoX app.)

"laucherscriptcr' is the one in charge of opening back the DB's (it must be customized for your server file names etc.."

One last note, this is for a single server config, FMWSC and FMunlimited running on the same server. I am working on another script for a 2 server config..

And Finally if anybody has a Clue of what is going on or what causes the crashes PLEASE Advice...

OSX users may want to have a look at Whistle Blower and an APC master switch(s).....very very good for checking all of your LAN and public servers are up and running.

http://whistleblower.sentman.com/

WB can disable checks based on the results of others e.g. you don't end up restarting your webserver because of missing content when your DB client or server has crashed.

I run two OSX.2.3 FMPro U 6 clents with no problems.... OSX FMPro server 5.5 had two installs before it would run properly... Why?..... who knows. It works fine now tho.

File names seem to be very important. The Apple front end allows you to use extended charaters in names of files. As soon as the underlying UNIX has to access the file you could have problems.... if it is being accessed by an application or daemon you could have a nasty crash and possibly corrupt files.

We keep filenames short (less than 31 chars. and only use a to z

I am having exactly the same problem with FM Unlimited running in OS X. I have two systems: FM 5.5 Unlimited on OS X 10.1 and FM 6 Unlimited on OS X 10.2. Both unexpectedly quit every now and then (at least once a week) for no apparent reason. I am also running a copy of FM 5.5 Unlimited on an old Pentium III with Windows 2000 - this machine has not been rebooted in 18 months (FM has not been restarted either) and FM has not crashed once!

I am having the same problem as well running FMU 6 and FM Server 5.5 on Mac OSX 10.2.3. It sounds like the only solution thus far is to restart the server every or every other day. Since this isn't a very appealing workaround, are there any other solutions to this problem?

Thanks, in advance, for any suggestions!

Well I don't have much experience with FMU, but I know that OSX unexpectedly quitting is more common than we all would like. I have a G4 867 that unexpectedly quit frequently when writing to the HDD. We used a drive utility (I think it was called Drive X) because there was some shell data corruption, and when the repair was executed, the quits were almost all the way gone.

Ken

Has anyone seen a solution to this? I recently upgraded FMU 5.5 to FMU 6 on OS 10.2.4 and now FMU fails every 1-2 days. Prior to this there were no problems. When this happens FMU becomes extremely slow and the processor is at maximum. Of course FMU is using nealy all of the processor.

Has anyone seen a solution to this? I recently upgraded FMU 5.5 to FMU 6 on OS 10.2.4 and now FMU fails every 1-2 days. Prior to this there were no problems. When this happens FMU becomes extremely slow and the processor is at maximum. Of course FMU is using nealy all of the processor.

I know you will not like me: get the Windows

10 years ago I was always writing: get the Mac!

But in 5 years after my switch from Mac OS to NT4 and W2000 I didn't experienced

any problems. For sure less in 5 years that you experienced in a week.

Hi, folks!!!

FOLLOW-UP.

I am pleased to post a success story, although it may not help some folks who seem to already have simlar set-ups.

FMP-U 5.5 w/5 databases (only 1 has significant every-minute traffic).

We went from a PowerMac on Mac OS 9 to a beige G3/300 desktop (192MB RAM) with Mac OS X 10.2.4 and it has been running flawlessly for months now, with only an occasional (monthly?) re-start for Apple's software updates (not for problems). It is ROCK SOLID. I used to have to check every morning if it was running properly, but each day my confidence has grown and now I don't bother... even for weeks.

Our other system (G3/300 Server, X 10.2.4, 128MB RAM) runs FMP-U 5.5 in Classic and re-boots every day in the wee hours using CRON from the command line (we use a mail plug-in that is not available for X yet so must run Classic). We are very happy with this workaround. What's nice about this is that you can log into the system remotely (command line) and manually re-start the computer if FMP-U quits (which it rarely does now). Upon restart, we have X auto-load FileMaker and the 1st database and then have the 1st database execute a script upon opening to open all the other db's. We did this latter step because we could not get X to open all the db's. It would only load the first and then ignore the others.

I hope this helps some folks. For our pure X system, we did a full format/install from scratch, of course. In fact, we did not even install Classic, so EVERYTHING is X, and it is working GREAT... better than I had hoped.

Hi

Well I got FMP6 U on win2000 adv server on a Compaq proliant dual P_III win 512MB mem, and it is running for 5 months now without any restarts...and the traffic is 200 entrances per day...

I too have been experience similar problems where no problems existed in OS 9.2.2

Last Summer I upgrade from OS 9 to X 10.1.5

This winter I jumped to X 10.2 (currently at 10.2.4)

Over the last month I have had the following crashes:

( They are all listed in crashreporter as

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_PROTECTION_FAILURE (0x0002)

Date/Time: 2003-02-26 17:13:12 -0500

Date/Time: 2003-02-27 07:24:10 -0500

Date/Time: 2003-03-03 10:12:49 -0500

Date/Time: 2003-03-03 17:59:15 -0500

Date/Time: 2003-03-05 10:39:43 -0500

Date/Time: 2003-03-09 11:33:02 -0500

Date/Time: 2003-03-09 18:06:33 -0500

Date/Time: 2003-03-10 15:48:34 -0500

Date/Time: 2003-03-13 10:36:03 -0500

Date/Time: 2003-03-13 17:56:55 -0500

Date/Time: 2003-03-14 11:17:10 -0500

Date/Time: 2003-03-16 19:04:52 -0500

Date/Time: 2003-03-24 15:52:34 -0500

(So 13 crashes in about 30 days.)

What I do now is have cron execute an applescript every 5 minutes to check to see if FMP is up and opens it if it is not up.

Generally speaking this works ok but sometimes things get fouled up with dialog boxes and it requires manual intervention.

I would love to see this fixed -- if anyone have more insight fire away.

BTW G4 dual 533 1GB RAM - running FMP Unlimited, Lasso 5, WebStar.

Smorr:

Hi, by looking at the error message given, i would guess that some process in FM is trying to access the protected OS memory space. You didnt say what version of FM you have, but you may want to check for an update.

Ken

RE: BTW G4 dual 533 1GB RAM - running FMP Unlimited, Lasso 5, WebStar.

AFAIK from Lasso List, there where some Lasso issues on Dual CPU, and I believe it is fixed in latest Lasso 6.0.4.

Also the speed is improving with every version of Lasso 6.

Well, this is the original poster. things are OK now because I went back to OS 9.2.2 instead of running under 10.2.2. I think my problem was twofold. First, there was lingering corruption in the databases due to crashes over the years. According to FM Inc corruption can be magnified during the DB conversion in version chnage, and these had been through 3-4 to 5-6. Also, there was some crashing that occurred recently under OS X, having to do with a DB that was corrupted that Server 5.5 was able to open causing problems when accessed via the web under Unlimited. What I did was retrieve copies that had not been through the OS X crashes, install them on a test OS 9.2.2 machine with a freshly installed and upgraded (v2 & v4 Web Companion) copy of FMU 5.5, and tweak the password privileges, default passwords, and Web Security privileges so that all DB would open with no intervention on a restart. I thne set the Energy Saver control panel to restart every day in the wee hours. After running for a week or so in test mode I copied everything over to the production G4, set it to boot in Classic, and let 'er rip. Everything has been solid since, about a month now with no downtime.

I think the lesson learned here is to use better practices in terms of implementing solutions. Because of the ease of use, self repair on restart, and easy painless converion through versions of FMP, I became (was? am?) lazy and made changes to production versions and migrated them through. What I should have done was to have the normal environment, separate test & production with clean, empty, archived copies of all solutions burned to CD to fall back on. Also for 5.5 I found that it was doubly important to upgrade everything. Part of the problem I had was not upgrading the Web Companion. I did upgrade the FMP version right away, but not the Web COmpanion. If I satayed with tthe stock v2 stuff it gave horrible crashes when accessed via the web. Upgrading to v4 on the Web COmpanion cured that, but by that time I had domne some damage to the files. Going back to previous versions of the DBs cured that as well. Live & learn!

HMMMM.....

My earlier success story seems to have been premature even though I had waited months to post. Without any significant changes to software or db's, all of a sudden we've had about 4 unexpectedly quit errors over the past 2 weeks whereas we had had several months of rock-solid performance.

We'll probably go back to CRON and restart each day if the errors continue, but it was REALLY NICE these past many months when it was all good. Or maybe we'll give smorr's AppleScript idea and valentc's (and FMFORUMS adm/mod's tips from other posts) to rebuild corrupted db's (or Vaughan's tip of saving an empty shell as a backup for re-importing data if needed). Unfortunately, our db was first made in FMP 2.1 and has grown over the years so going back to previous versions won't help much... gotta go from scratch, I guess.

Still, in the mean time, restarting each day at 3am is not a big inconvenience for us so I'm not going to start remaking our main db today... I'll just save it for "later" (wink & smile).

"Nudged Out of the Sweet Spot"-ingly Yours,

ST

FOLLOW-UP #3:

Well, it seems once every 1-2 months, FMP either unexpectedly quits or just stops serving on the web (everything looks ok on the admin side). At this point, we are not auto-rebooting the all-X machine since it is non-critical information and these problems are still infrequent (unlike some of the every day quit folks). As of today 7/11/2003 there are posts mentioning Netscape 6.0 and/or interrupted requests/loads as possible culprits.

User dwal already links that thread to this one, so I am linking this one back to that one... I hope the answer ends up in one of these threads someday...

Unlimted Stops Hosting thread

We are still happy with our MacOS X 10.2.4 / FMP-u 5.5 combo, though... despite the occasional quits/stops. We're now running 8 db's on it, although some are internal and light load. Good luck!

We recently moved from Filemaker 4.0 (not even 4.1) on OS9 over to Filemaker 5.5 Unlimited (with all current updates) on OSX 10.2.6. It has been a very bad experience. It was stable in FM4/OS9, but now we have daily crashes - usually multiple crashes a day. I have been in touch with Filemaker and done everything they suggested (full recovers and all that jazz). We even broke down and bought a 1.25Ghz G4 and moved it all over there but we still have crashes (only now we recover faster ). The only suggestion from FM support now is to rebuild our databases from scratch, which is insane considering this software is a product that has grown over 10 years and has plenty of dbs and plenty of fields.

While there are no consitencies in the logs that are helping be track down the problem, it does do the same type of crash every time:

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_INVALID_ADDRESS (0x0001) at 0x07661608

Thread 0 Crashed:

#0 0x05369eb0 in Run__Q22wc13TaskQueueImplFRCQ22wc15Ref<Q22wc4Task>

#1 0x054104bc in Run__Q22wc15FMTaskQueueImplFRCQ22wc15Ref<Q22wc4Task>

#2 0x053167c8 in RunMainAppTasks__Q22wc19AccessCompanionImplCFRCQ22wc15Ref<Q22w

#3 0x0532a214 in HSRV_NetworkIdle__Fv

#4 0x0528365c in FMExternCarbonCallProc

#5 0x0040f690 in CallFMExtern

#6 0x004110f8 in FMXC_Idle__FUc

#7 0x003c2308 in DOC_Idle__Fv

#8 0x003fff8c in DispatchNullEvent__9CFMProAppFRC11EventRecord

#9 0x00619694 in 0x619694

#10 0x0061938c in 0x61938c

#11 0x0061928c in 0x61928c

#12 0x00607094 in 0x607094

#13 0x003fee38 in main

To me it certainly looks like a bug in Filemaker. Even if it IS some type of corrupted database, you'd think the software could catch the exceptions or whatnot and prevent unexpected crashes and maybe help me narrow down where the problem is ("The file X is corrupt and would have caused Filemaker to Unexpectedely quit if we weren't good coders and caught this exception"). Rebuilding one database from scratch is more likely than rebuilding all 45. So this IS a bug - any way you look at it. I've tried going back to OS9 with FMU5.5 also and I've still had crashes - and those usually take the entire system down. At least in OSX I can recover better.

We're not thrilled right now about spending the $1,000 on FMU5.5 (last year sometime) and from what I understand, FMU6 has the same problems and wouldn't be worth the price of the upgrade. Going through these forums makes me realize that we're not alone with all this. Why isn't there better error handling implemented yet?

I might have to strip out the minor updates we've made and go back to FM4.0 on OS9. That will take a good deal of time though and leaves me very little faith in all things Filemaker.

Any new suggestions for my problem here or thoughts on how to get Filemaker to fix this bug would be great.

AND IT JUST CRASHED WHILE WRITING THIS.

Hi, there! I feel your pain and can sympathize even though I'm in pretty good shape right now myself. If crashes are that frequent, maybe try testing in small sets as you kinda hint at... maybe 5 sets of 9 db's tested 1 set at a time (or however they break cleanly). Or maybe you could run both FMP4 (for most of yor db's) and FMP5.5-u (for the few db's that need the extras) if it's not all wholely intertwined.

I have NO idea what your error message means... I've never seen anything like it. I think a friend of mine said something about new Macs having a new kernel in the OS, though, so maybe it's a new incompatibility for which FMP, Inc. has to put out a patch? I dunno. We use 10.2.6, too and don't have trouble on our humble 300MHz machines.

Sorry. Maybe someone else will know more. --ST

Well, I've reverted back over to OS9 and now at least the machine stays operational for our employees to use it all day, BUT, as soon as I quit out (but fortunately after all the files are closed safely) OS9 freezes. I need to quit out to do backups of our data (and yes I am researching a Filemaker Server option for hosting the db's while FMU simply serves them to the web). But anyway this really sucks because I access our server remotely and once it freezes it's all over. I assume the corruption that is killing the OSX version unexpectedly is probably causing OS9 to freeze on quit.

Any thoughts on that?

I hate to admit this, but FMP (all versions) are much more stable (and faster) on Windows. IMHO, you should switch to a PC.

Without testing your database myself, I don't know for sure if this will solve the problem, but I think it is definitely a strong step towards stabilizing a production platform. I always advise against using Macs & FileMaker in a production environment, simply because they're not very stable, and to a much lesser extent because FMP runs much slower on Macs.

This is not to say that FMP on Windows is fault proof - it may crash there as well. However, I still say it is many, many times more stable on windows. Sorry .

Also, I think you should definitely invest in FM Server if you have multiple users accessing the database. You'll only need FM Unlimited if you have more than a few (10?) ip addresses pinging FM Unlimited within a 12(?) hr period. If you have a middleware app, like Lasso or PHP or ASP, then only one ip will be pinging the web companion (the IP of the machine running the middleware) and you won't have to worry about using Unlimited.

You can use FM4 or FM5-6 Unlimited ONLY for web serving of more than 10 IP's in 12 hours. Not using FM5-6 Unlimited in such case is against FMI license or FMI may call that unlicensed usage, who knows.

Hi there!

Glad to find this thread, im having problems serving a web database reliably with OSX 10.2.6 and FM-U 6.0v4

I bought a g4 dual 1.42 mhz with a gig of memory to sereve our solution and it has been a great disappointment. I get "unexpected quit" almost every third day. The is performance is also slow.

Here are some of my observations for how and when it happens:

1) I suspected the cause to be the use of Scandinavian charaters in user names when logging inn. It happens almost instant when these characters are presented as a user name.

2) Another possible cause could be attack of the nimbda worms on the server, i sometimes see these random URL requests on the access logs prior to a unexpected quit.

3) Today i worked on a copy of the database at home, on a G4, it quitted on me, when checking the base at work it had also quit almost simultaneously at a time around 13.00. My unexpected quits are usually at this time of the day. This suggests there is something connected to time issues/time localization that generates this?

I'm very glad for any help. Maybe someone should make a poll if everyone experience this kind of quits?

Also: Will it make a difference to run Filemaker in classic (i cant bot into os9 with this G4)

Thanks!

Gisle

I keep popping back to this forum in the hope that someone is able to post a solution to this very frustrating and potentially damaging situation. I work at ULTRALAB, a learning technology research lab where we use and have used Filemaker extensively for many web delivered projects. I feel very despondant wth using Filemaker at all now - it just isn't stable yet I continue to plug it's versatility as a web database platform that allows rapid prototyping and development to take place.

I am running FM 5.5 Unlimited. In OS X 10.2.6, filemaker unexpectedly quits several times a day. I have even written an AppleScript which checks to see if Filemaker is running (every minute), if it isn't, it launches the FM application and opens all the databases. This works a treat until you discover a corrupt database which needs recovering (happens once every 3 days)

The project involves 400 people and the database receives over 1000 page requests a day. I am confident that Filemaker can support this activity - it isn't that much in the scheme of things.

In desperation, I have tried many options. I have now moved the databases to an OS 9.2.2 machine. Filemaker now runs for a day and a half without crashing (same no of hits) but it still crashes!

Something to note is that once upon a time I did have Filemaker running reliably for months and months using OS X 10.1.5 - not sure why. When I upgraded it all went belly up.

I have been in contact with the technical team at Filemaker. They suggest using uncorrupt copies of the databases - as someone said, it's daft cos the databases will just corrupt again.

They mentioned the technical people are aware and are writing a patch - somehow i don't believe it - it has been too long already.

Any thoughts would be appreciated....

Read Mariano Peterson's contribution above.

BTW I am saying this for 2-3 years now.

Passing this on:

On OS X, this error can also happen if you are running our of vnodes (an

internal system resource). You can check for this with the commands:

sysctl kern.maxvnodes

pstat -T

The first command, sysctl, will display the maximum number of vnodes that

the system can currently have. The second, pstat, will display a couple

of bits of information. The one you want is the number of vnodes

currently in use. If the number of vnodes currently in use is anywhere

near the maximum you are probably having a problem with vnodes.

A vnode is a block of memory in the kernel used to keep track of files on

disk, and other several things, while they are in "active" use. When a

program opens a file, the system requires a vnode for the file and one

for the directory the file is in. Other things the kernel does also

require vnodes. For example doing a DNS lookup takes a vnode. Whenever

the operation is completed, the vnode is freed for reuse.

When a program tries to open a file, and there are no vnodes available,

the open will fail, even if everything else about the operation is fine.

This will cause programs to fail when trying to open a log file, or

writing a backup, or any of several other things. A few things other than

opening files also require vnodes, such as DNS lookups. As virtual memory

usage increases the system will use vnodes to keep track of the virtual

memory. Many other steps can also require vnodes

Certain system programs perform operations that must succeed in order for

the system to continue functioning. When one of their internal operations

fails, because there are no vnodes available, very bad things might

happen. Although everything is supposed to check for that kind of thing,

and try again, not everyone is that careful. Also there are a very few

kernel operations that must have a vnode right now, and can not wait for

one to be freed. If one of those happens and there isn't a vnode

available, you will get a kernel panic.

The solution is to tell the system to allocate space for more vnodes. The

command:

sudo sysctl -w kern.maxvnodes=20000

will raise the limit to 20000 till the next reboot. This must be run by

an admin user and will prompt for a password. You should watch the output

of:

pstat -T

to make sure that that is really enough. You want there to be a few

thousand free when running all of the apps you are every planning to run.

If not, raise the 20000 to something higher.

Hope this helps

This is interesting, Fred.

On a side note, unexpected quits can also be caused by bad memory. If you have a program like TechTools, then you could run it and see if you maybe have a bad RAM chip.

In my experience, FM 5.5 or 6 runs the best on Windows 2000. BUT, we have been running FMU 6 on OSX Server (from 2.1 to 2.8) for about a year now and have had no problems whatsoever.

Could Panther be the answer you think???

Released on 10/24/03, FileMaker Web Companion 6.0v2

ftp://ftp.apple.com/filemaker/Updaters/MacOSX/wc_60v2_osx_update.sit

From the Read Me file:

Fixes a problem that caused Web Companion to become unstable or quit when sharing databases from Mac OS X 10.2.

Panther appears to be the answer for Macintosh. Last Friday I upgraded our server from Jaguar to Panther. There have yet to be any problems! Prior to this FileMaker Unlimited v6 would stop responding after 36 hours or sometimes sooner.

bigfundj said:

Released on 10/24/03, FileMaker Web Companion 6.0v2

ftp://ftp.apple.com/filemaker/Updaters/MacOSX/wc_60v2_osx_update.sit

From the Read Me file:

Fixes a problem that caused Web Companion to become unstable or quit when sharing databases from Mac OS X 10.2.

I wonder if Filemaker will be kind enough to fix that same problem in the 5.5 Web Companion. I'm sure they know it's there too - and I'm sure they fixed the current version first. Anybody have any idea if they will go back and fix the 5.5 version now?

It has been a while since I have posted - but it is nice to know that others now have the same troubles we struggled with for the past 2 years.

Under 4 and OS 9, (FM Server on NT) - the solution was bullet proof.

Upgraded to 5.0 and Windows 2000 (Web companion on OS9) - bullet proof for a while - then Windows 2000 had a Nambda virus patch applied and the crashing began. We upgraded to OS X, no good, FM5.5 - no good, and finally sadly turned in our Mac and ran it on Windows 2000. Better stability but still needs a reboot once a week. Now the crashing is increasing over the past month.

I am still amazed that Filemaker has not addressed this issue better as it is obvious that many are having troubles (anyone for a clash action lawsuit ;-) )

I am hoping they come out with a 6.02 patch for Windows soon and hopefully there is some news that Version 7 will be more stable. It is getting tough to preach "Filemaker is great" when the site has to be rebooted.

Anyway - no solutions here - we have tried everything all have suggested and now we wait for Filemaker to come up with a fix.

Perhaps Panther, FM6.02 unlimited, etc is the solution...

I plan to upgrade to Panther Server with the latest version of Filemaker 6.0v2 Although i haven't had Filemaker quit unexpectedly since i installed the update (2 days ago) Filemaker has hung twice. Here the databases and the application are open, in fact i can swop between OSX apps and Filemaker, but there is no response at all from Filemaker, force quit and relaunch is the only fix. Might be something to do with vnodes.

I do wonder whether the latest FM update works in 5.5, are the web companion plugins written just for FM 6.0? Has anyone tried it?

RE: Upgraded to 5.0 and Windows 2000 (Web companion on OS9) - bullet proof for a while - then Windows 2000 had a Nambda virus patch applied and the crashing began.

We didn't have slight issue with FMU 5 and NT4 server. How you connect the W2000 to WC on OS9? Is it with Web Server Connector? In that case maybe there is conflict between patch, IIS and WSC. WSC is hmm -- not the best application around

I have now taken the bold step of Installing Panther server running Filemaker Pro 6.0 Unlimited. So far looking good for stability, by now I would have expected at least 2 crashes in the four hours it have been running. Not brave enough to say it's fixed just yet though!

Did you reinstall Win2k from scratch after the Nimbda virus? Because the patch will DELETE any file affected. This includes app and system files. That virus is also able to spread to other PCs on the network. So crashing might result from that.

jfurness...

I too have had a lot of the unexpectedly quitting of v6 of unlimited on OSX. Both version 10.2.6 and 10.2.8. Was curious what updating to 10.3 has done for your problem.

LR

Good point.

BTW -- it is Nimda. Read it backwards

Greetings from a new member...

I recently moved from a Win2K server to a dual-G4 XServe (running OS X 10.3.1, Apache 1.3.28, PHP4.3.4, FX.php and FMU 6.0v2). While configuring the machine, everything seemed to work fine, but as soon as we swapped servers I started getting the FM freezes that jfurness has experienced. It was happening 3-4 times/day, and got so bad that we went back to the Win2K machine until we get it sorted out. We've got a FM support tech working on it, but he seems as baffled as we are.

Has anyone found a solution for this problem?

I've got another one that perhaps someone has seen: Sometimes (let's say "semi-reliably") FMU will just quit cold when a particular PHP file sends its request to Web Companion. We have to restart FMU and go through the whole file consistency check process. It happens on both the Win2K and Apple servers. The file is more complicated than most, but not essentially different from others that work fine. Does this sound familiar to anyone?

Regards,

sydlexic

Hi:

I noticed that you said that your version is 6.0v2. There is a 6.0v4 that I would try upgrading just to be sure.

That was a typo. I'm using 6.0v4, with the recently updated Web Companion files.