What fails on Windows but works on Mac?

[Moon]

I posted something along this line in another string in this forum, but am asking for ideas as I am baffled.

The situation is this: Using files from the FileMaker Solutions Framework obtained from FileMaker I developed a human resources management system with a dozen files for a client. Nice set of systems with a lot of work already done. I like the setup and appreciate Matt Petrowksy's generosity in making it open and available to all. I did (and do) all my development on a Macintosh, as I have for 16 years. However, for the first time, ever, some of the files in the system force FileMaker to quit when opened on Windows. I have tried the files on three different windows machines running Windows 2000, Windows XP, and Windows ME. Same problem on all three computers. I am stumped, because all of the files open and operate on Mac OS 9 and OS X. So here is my question to all and sundry:

What kind of faults in a FileMaker file are ignored by Mac but cause Windows FileMaker to shut down? The answer is obviously important to me because I have a client who has been patient but is anxious to use the system, not to mention I would like to receive my final fee payment.

Please throw me anything you may know about solving this. I have seldom encountered something that was so exasperating in its obscurtity.

Thanks in advance.

[Moon]

I mean "obscurity." Fingers fly at their own option when I type.

[T-Square]

I can't help you with your problem, as it's the same one I am encountering. I have a system that I developed on a PC, which is being used on a Mac by my client. I recently needed their files to do a major upgrade, but cannot read any of the files they have sent me. I am running FM4.0 on Win2k. I'm about to the stage of exporting all their data to text files and importing them into the updated version...

David

[DykstrL]

Moon, it almost sounds like you might have a corrupt graphic image on a layout. Try this: on the Mac, set the file to open on a blank layout. Then open the file on the Win machine. If it opens to the blank layout OK, then try to go to the normal open layout - if it blows up, there is something - usually a corrupt image - on the layout.

I have seen this before, but it's been a while (version 3). I don't know why - it seems that the Macs ignore or can tolerate some types of graphic corruption where Windows has a fit and blows up. If I had to guess is that FileMaker on the Windows side is sooooo dependent on the video and the printer drivers to paint the screen.

The solution is to start deleting elements on the layout one by one until it will open on the Win machine - either that or delete the whole layout and start again from scratch.

[Moon]

Thanks for your response, and the good advice. This problem spinned into another which ought to be in the Developer thread, probably, under How To Handle a Macintosh-Phobe Client. I'll describe that in a minute.

I am going to do use your approach on the files that failed to satisfy my professional curiosity, although I took another approach that seemed to solve the problem. I had used the FileMaker Solution Framework to create the solution, and after tinkering a little after the Great Big Windows Bomb I discovered a preference setup that included an option to maximize windows on Windows platforms that was checked. Don't know why I turned it off (deep rooted intuition with no rational thought whatsoever), but when I did the files all opened normally on the Windows machines at another client's office (which, by the way had also failed on the same files before the change I made). Why that should have made a difference, I don't know, unless perhaps there is a graphics fragment that displays when Windows opens the layout WAAAY up. I suspect that may be the answer, but I would not have thought of it without your suggestion. Thank you again.

The client for whom I created the solution was less than reasonable, in my opinion, in her reaction to the intitial crash. She leaped to the conclusion that because I had developed the system on a Mac that she would be forever fighting the Cross-Platform Curse which she had experienced with graphics files that she had encountered from designers who did their work on Macs. Although I explained that graphics and FileMaker files are entirely different entities and that her experience with graphics was not applicable to this situation, she shut down on using the solution and so far is stiffing me for the remainder of my fee. Inasmuch as this is the first time I have had a client who refused to try to work through glitches at the earliest phase (this was upon the initial installation of the system, and we had agreed that we would need to work together to finish up any problems that popped up.) For me this will be a learning situation to deal with clients who refuse to pay (and in this case, to work in good faith), and I anticipate a trip to the small claims court before it is all finished, although I hope to salvage the client, the project, and my fee by working out the dispute if I can.

Sorry for the digression. I am taking your advice today on the possible corrupted graphic and will see where it leads.

[Gogargirl]

Well, I had a problem a few months back when Filemaker (Windows) shut down on me everytime I tried to perform a Recover. Through the forums someone suggested I should move the file up the directory - the long path name was the issue - and it worked.

Which verson of FM are you using? I just upgraded to 5.5 and then checked the fix list for the latest updater at filemaker.com. Seems the 'long path name shutdown' was a bug they fixed. They also list an issue where a Set Field script step in Find Mode will cause unexpected shutdowns. The updater fixes this.

HTH!

[RussBaker]

I recently had a problem with a Mac developed solution which was deployed on a PC. The relationships wouldn't work unless the various child files were all opened up manually first. This didn't actually crash the PC, but the solution wouldn't work.

On closer inspection, I found that when loading the files onto the PC Hard Drive, they had all become "Read Only" - cause unknown, but they were loaded onto the PC from CDROM.

Once I got rid of the "R" status in properties, everything worked fine.

[kenneth2k1]

In case you were still wondering...

Yes, some spiffy Microsoft engineer years ago thought that it would be such a good idea to have all files that are transfered from CD to Windows be read-only. Then you have to go and change it. I bet he thought he was pretty cool, although I would like to strangle him for whasting alot of my time.

Ken

[Anatoli]

You are too gentle to him

[Guest]

As a total nitwit to FM i have a related question

A company i know went from Mac based to windows based systems

They have big problems with dissapearing decimals.

When moving from Mac to windows does one need to "convert" the files in anyway or just rename them to .fp5 ?

or does this depend on version ? (version of creator/server/client ? )

sever now is winXP with FM5

Thanks in advance

Steve

[Anatoli]

I went that direction and nothing was problematic.

The same things, which were problematic in Mac, stay problematic in Windows, something like Central Europe characters in ODBC or Web.

My workaround was the same for Windows and Mac.

Try to set the same format number for all machines and start databases with "Use system format".

That should help.

HTH

[mgb99]

Ok, maybe you can explain the reason for this problem re Win2k and XP. (I had previously posted a description of this problem in the plugin's forum, but it is a Windows issue that happens to involve using a plugin and thus generated no responses.) I have developed a backup system utilizing the Troi file plugin that creates a backup folder in the runtime application's folder, stores its path and copies the user's data file as a backup into the backup folder after closing the original data file. It works perfectly in Mac OS X (Native and Classic), OS 9, Win98 and Win ME. However, in Win2k and XP the backup folder is somehow created in the desktop folder and backups do not get written since the path (I presume) is no longer correct. (I tried changing the path for creating the backup folder and for storing the backups to root level. The backup folder is now created at root level (e.g., C:/Backup Folder), but the data file is still not writing correctly even though its path is correct (e.g., C:/Backup Folder/DataFile.USR).) I presume that this is a permissions issue in Win2k and XP, but I'm a Mac person that doesn't have the eXPerience in WinTel to figure this out. Any thoughts on how to fix this?

[Anatoli]

Why don't you leave this job to FM Server?

[Guest]

Unfortunately, this is a runtime only application. The individual users are not related and have separate data files/backup files.

[john white ifc]

I've been following a discussion (on a listserv for FM developers in southern Ontario) about the issue of running FMP:4 on W2K. Since the latter didn't exist when the former was being written, there could be problems. In the opinion of the weightier authorities, it was not a good idea, and upgrading to the latest (W2K-Certified) version was recommended.

If of course you have any choice in the matter.

No one could point to any specific, known problems. But the attitude was, application versions that pre-date OS versions just don't mix with mission-critical data.

If you like, I can send you a summary of the discussion.

[john white ifc]

I heard about this. Your "cause unknown" is jsut the standard way that Windows deals with files copied from CDs: it sets their read-only flag. I guess the rationale is, if it was read-only by virtue of being on the CD, it should remain that way. Whudd-EVuh.

[john white ifc]

Dear Moon:

I composed the following message after reading your original posting. I'm glad you've found your fix, but it means the follow not a problem-solver, just a little shared experience.

_____________________________

I have had a couple of incidents along these lines.

In the first case, I took over a client's 12-file system and ramped it up considerably, with lots of scripts, relationships, access privileges, the works. All development on Mac, all users were Mac, hosted by FMS. Then we made it accessible to the handful of Windows users here and *one* of the files kept crashing the system. If memory serves, I ended up performing a recovery on the windows machine and deploy the recovered file. I don't think I did a lot of testing with images or fonts or specific layouts. I certainly had no graphics other than FileMaker objects, although I was using Zapf Dingbats.

If memory serves, this was before we upgraded from FMP:4.0/FMS:3 to FMP/FMS:5.0. The Windows boxes were running Win 95 at the time.

_____________________________

The second incident occurred last March, same client. In one of the files (a different one) my password settings had gotten corrupted. I contacted FileMaker's tech support (Hudson Akridge handled my case very proficiently and competently), sent them my files, they Recovered the problematic one, sent it back, I deployed it and everything was fine.

The mystery was, I had already tried recovering the file and it hadn't helped. (That's why I contacted them in the first place.) I did a little Q&A with Hudson about it, and you might find our exchange interesting.

I wrote:

> why would my Recover not work when yours does? (I'm using FileMaker Developer

> 5.5 v1 on Mac OS 9.2.2.)

Hudson wrote back:

> The differences as far as the systems are concerned: I am running Win98se,

> Running FMP 5.5 not developer. Those two things alone might have been why the

> recovery option was different. The header files are stored separately for each

> Operating system. So when recovery runs on a PC it is different than it

> running on a MAC. The recovery option could also be modified or altered by

> programs running.

I asked:

> What are header files, and what role do they play, both in Recovery and

> generally?

He replied:

> Header files are really what stores the base information of the file. All of

> your indexes/passwords/field definitions/relationships etc. are all stored

> in the header. When I say header files I really mean header pieces, as they

> are pieces of a whole. In recovery the different OS's recovery system will

> rebuild the indexes and header files differently, so recovery on a PC may

> work better than recovery on a MAC. It is sometimes unpredictable though, so

> rarely used as a standard troubleshooting method.

Best of luck. Let us know how it turns out.