Server 5.5v4 Damages databases

[SoCalMacDude]

I have some databases hosted on Server 5.5v4, MacOS 10.3.9.

When you click "Stop Server," it never will stop, just says it will take several minutes, but never finishes. Rather than force quit, I restart the Mac (from the menu), but when it comes back, it says the DB's are damaged, even to open them in FM 6.0v4.

I always recovered, then imported into a good clone, not using a recovered database.

I have formatted the hard drive, installed a new 10.3, upgraded it to 10.3.9, installed a fresh Server, upgraded it to v4, problem persists.

Any ideas???

[Stuart Taylor]

have you checked the log in the filemaker Server Folder...

This can happen if a user on the network keeps opening a database when the server is trying to stop or if someone on the network is running a script or there script is paused.

I would reinstall... ive had no problems with 5.5v4 and have many clients running it on many environments.

The only time i ran into srouble was when a clients install disk was scratched ... bazaarly filemaker installed but had wierd behaviour ... i installed with a disk image and it worked perfectly.

This is the kind of behaviour 5.5v1..2..3 had but not 4

Edited October 31, 2006 by Guest

[SoCalMacDude]

Good point, the log!

When I asked it to close, it closed many databases, but the big one (75Mb, 35,000 records), it never confirmed the close, log stops 3 databases later, with no entries for the last 8 databases.

Here's the end of the log ( I noted the bad spots with an asterisks)

Oct 30 11:53:14 Flanders-Computer.local INFO: Closing file "Flan_Cust.fp5"...

Oct 30 11:53:14 Flanders-Computer.local INFO: File "Flan_Cust.fp5" closed.

****Oct 30 11:53:14 Flanders-Computer.local INFO: Closing file "Flanders.fp5"...

Oct 30 11:53:14 Flanders-Computer.local INFO: Closing file "HB by Style"...

Oct 30 11:53:14 Flanders-Computer.local INFO: File "HB by Style" closed.

Oct 30 11:53:14 Flanders-Computer.local INFO: Closing file "Include in Price List"...

Oct 30 11:53:14 Flanders-Computer.local INFO: File "Include in Price List" closed.

****Oct 30 11:53:14 Flanders-Computer.local INFO: Closing file "Label Database By Part No.fp5"...

There are 8 more left to close, this is end of log. "Flanders.fp5" ends up damaged.

Same problem as before I formatted the HD, reinstalled.

There is only 1 or 2 users normally, no one was on when closing.

Maybe I'll see if I can find a disk image to install from.

[Stuart Taylor]

How long are you waiting for?

Have you timed it...

It may just not have finished.

[Stuart Taylor]

Question...

Are you all accessing the database via File/Open Remote or are you clicking on the files in the filemaker server folder?

[SoCalMacDude]

Waited 2 hours, used to take 3 minutes.

Access is ONLY through Open Remote. Clients are PC's (there's the problem ;-)) just kidding!).

Someone suggested it was hard drive - have already run Disk Utility, and did Sudo Periodic Daily, Weekly and Pre-bindings in Terminal. S.M.A.R.T. status shows Verified.

Seems OK?

Edited October 31, 2006 by Guest

[Stuart Taylor]

have you tried taking out the suspect file/s starting and stopping. This could point the problem directly to the files rather than the Server software

[SoCalMacDude]

Good point. Maybe it's one of the last to close (or the next one). I'll try that.

Therer are 2 that get munched, Flanders and HB by Style, which logs as closing OK.

[SoCalMacDude]

Another hint:

I grabbed a backup file that the server wrote last night, it says File not closed properly, checking consistency . . .

then opens fine.

I immediately close it, it says "Scanning for unused blocks" as if I had deleted lots of records. Then "Removing unused data."

Next time I open it, damaged!!

[Stuart Taylor]

If all else fails recover the files ... export the data and import it into an earlier copy of the files.

If you were ever running these files with a version earlier than 5.5v4 they may have been crunched a while ago.

Sounds like corruption.

Stuart

[SoCalMacDude]

I agree, it does sound like corruption. The files have been working and evolving for 7 years. I'm thinking of making the switch to FM 8.5.

The files are quite complex, but the relationships are fairly straight forward. When I convert, will the corruption be gone?

[Stuart Taylor]

I wouldn't chance it!!!

[SoCalMacDude]

Are you saying that we need to remain in FM6 forever? How tough is it to migrate to 8.5?

[Stuart Taylor]

I meant that i would not try converting a corrupt database ... it would just be asking for trouble.

[SoCalMacDude]

Right! I figured I would do a recover, then convert. Or, then import, then convert.

After all these years, I probably used a recovered database long before I knew that was unreliable. Now, of course, I recover & import into a good copy. The problem is, that copy may have been a recovered copy a couple of years ago.

Anyone know a method of cleansing a database? Converting to 8.5 won't rebuild it enough to leave the corruption behind?

[Ender]

Converting to 8.5 won't rebuild it enough to leave the corruption behind?

While it may work, there a good chance the corruption will still be in there just waiting to crop up again.

This may be a good time to rewrite the file from scratch. This way, you can take advantage of new features in FM8.5. While this sounds like a daunting task, it's a good opportunity to rethink the design and make things more efficient. It turns out, much of the work in a solution is understanding the business logic and processes. Since your existing file already has that, it's really not as hard as it sounds to reproduce that in a new file, adding the improvements of the new version.

[Stuart Taylor]

I have had situations where elements of layouts have gotten corrupted and others where chuncks of data and sometimes entire fields have corruption... so who knows where the problem lies.

I remember in my early days (v5) deleting a block of obviously corrupted records everything was fine for a couple of weeks but after a number of new records had been created the corruption reoccured in records that were fine before.

And after recovering a different file and stupidly redeploying it found that first all of the relationships had been stripped out and then after fixing to 2 weeks later got a call to say that records were dissapearing. After many hours of banging my head against a wall i found that one of the buttons that i had created had switched its definition to a script step that deleted records without dialogue.

Please learn from my mistakes and not your own ... i realize that you may not have another copy but think long and hard before you take your next step.

I have a project that took 3 years to complete (v6) and i have set myself 8 months to create it again from scratch in v8.5 I do not regret this at all as i know the structure and can really sort out some pretty poor early work with some of the new features available.

best

Stuart

[Stuart Taylor]

Ender ... you beat me too it by a few minutes ... We are both saying the same thing.

That should tell you loud and clear that this is most likely the best course of action.

Sometimes you just have to bite the bullet.

[SoCalMacDude]

Wow! Sounds like a daunting task.

It would be a tough sell to the customer. There are so many details . . . but using the new tab tool would make things nicer.

Just a quick look at the main file, there are 400 fields, 60 scripts, and some of the larger scripts have 100 lines of code!

We also have a Filemaker/Lasso web site based on old stuff.

flandersco.com

How custom can we get with IWP? Can I make it look like a web site rather than a database (like it is now)?

[Ender]

The amount of work kind of depends on how complex the interface is in that file. If it's pretty simple, rebuilding will be quick indeed. If the file is the main interface for its module, then it may take considerable time.

Since upgrading to FM7/8, I've rebuilt a number of modules, using the old layouts as the interface, but optimizing the relationships, fields, and scripts for FM7/8. If I had 6 months to set aside for this, I might be able to complete this effort on the rest of my solution, but it's more likely to take longer with my other duties getting in the way.

[Wim Decorte]

There was a nasty bug in FMS 5.5 on OSX that would corrupt databases, not sure when it was fixed.

But the easy work around was to close each file individually before stopping the service. I posted a shell script to automate just that and Jonathan Reff made a nice GUI around it and named it "closing time". Do a google on that.

Regardless of the version of FMS it's best practice to close the files first and not rely on the service stopping to do that for you. Should it work: yes. Had it failed in the past: yes. Once bitten, twice shy...

[SoCalMacDude]

Thanks for that!

I will check it out and probably implement it.

These databases really do a lot, and have so many tiny details that make them work right. I mentioned the possibility of rebuilding to the customer, and the reaction was almost panic. There is soooo much they need me to do, that a rebuild would set everything back too far.

I suppose I should take an OLD backup of each database, make it a clone, and import current data into it. Then wait for the complaints to come in to discover what tweeks are missing in the programming!

I really feel this was introduced when I went from Server 5.5v1 to 5.5v4. Didn't have the problem before, but I heard that for 5.5 to be reliable on OSX, should upgrade to 5.5v4.

I will try your stop server utility.

Thanks!