: does anyone have a list of known bugs in filemaker 9? I know there are some. (I'm sure filemaker is aware of most of them but, from experience they do not let the public know what they are until there is a fix. Good for sales, bad for everything else.) If there is a list, I'd love to see it. If there is not, I invite all to post any bugs they have found here.

(I once spent three months tring to figure out what was wrong with my solution only to find out that Filemaker knew of an indexing issue and did not publish any info on it until there was a revision that fixed it. I for one would like to avoid anything like that in the future.)

1) Attempting to open some pre-9 files in 9 without first saving as a compacted copy will result in an error message that appears to say the file is corrupted when it is not.

2) Trying to print to pdf can result in file crash and corruption under certain normal operating situations such as printing a page range or printing a layout which contain sliding objects.

"1) Attempting to open some pre-9 files in 9 without first saving as a compacted copy will result in an error message that appears to say the file is corrupted when it is not."

This is not a bug. The file *has* some corruption. FMP 9 reports the corruption that older versions would have ignored.

Well, I guess it's just my night to disagree, Vaughan.

I believe that ALL files created in prior versions will open with the scanning message and this does NOT mean they are corrupt. I just tested by creating a brand new file in 8.5. I imported 5,000 records so, when I opened it in vs. 9, it would take long enough to see the opening message.

It scanned it.

LaRetta

"I just tested by creating a brand new file in 8.5. I imported 5,000 records so, when I opened it in vs. 9, it would take long enough to see the opening message. It scanned it."

Are we talking about FMP 9.0 refusing to open a file because it's corrupt? Or FMP 9.0 scanning files it opens?

I've been using FMP 9.0 since before the release date, and I've only had to compress an old file maybe once or twice. The others were fine.

As a test I just created a new file in FMP 8.5 (using the the Purchase Orders template) then immediately opened it in FMP 9.0: no error message.

[color:red]Everyone should pay attention to what Vaughan said.

FileMaker Pro 7, FileMaker Pro 8, and FileMaker Pro 8.5, along with FileMaker Server 7 [color:red]do not perform any consistency checks on files. FileMaker Server 8 does as does FileMaker Pro 9.

Steven

I've been using FMP 9.0 since before the release date, and I've only had to compress an old file maybe once or twice. The others were fine.

And you continued to use those 'corrupted' files?

How did you know you could save as compressed in 8.5 and continue using safely? Certainly not from the error message you received.

I think it's great FM9 performs a consistency check, however the error message when opening some pre-9 solutions is misleading. The message isn't "Save this file as compacted in a previous version of Filemaker." It's "This file is damaged, please use Recover" or something to that effect which is needlessly frightening and from everything I've read about Recover, awful advice. Bug.

Edited August 27, 200718 yr by Guest

"1) Attempting to open...

This is not a bug.

I agree, I would call this a "known issue", not a bug. However, I think the following is a bug

3) Page setup does not change the paper size correctly for some printers. (is also true for 8.5v2, works in 8.0v3)

Edited August 27, 200718 yr by Guest

I don't like the error message either, and I tried to get it changed.

Steven

I think it's great FM9 performs a consistency check, however the error message when opening some pre-9 solutions is misleading. The message isn't "Save this file as compacted in a previous version of Filemaker." It's "This file is damaged, please use Recover" or something to that effect which is needlessly frightening

I agree. And it wasn't a 'known' issue until MANY people received the error on their perfectly good files and jumped out of their skins. No, it is not a bug ... just poor communication and judgement on FMs part.

Not to mention the thousands of users who do not subscribe to message boards or read tech infos, are therefore unaware of anything except what FileMaker tells them in the message, and are happily (for now) running recovered files as their main business files.

I don't like the error message either, and I tried to get it changed.

Steven

We know you're on the side of the Good, Steven.

Curious though, sounds like FMI was aware of this issue before pre-release went out. Is that true to your knowledge and ability to answer?

I agree, I would call this a "known issue", not a bug.

Your thread, your call. :

Has anyone found any other "bugs"? (Issues and changes in behavior I can deal with.)

I doubt this is a bug, but thought I'd ask this here.. In FileMaker Pro Advanced 9, I think that the Mac Platform is reported by Get(SystemPlatform) as "1" whereas in FileMaker Pro 8.5 and 8, 7, it is reported as "-1"

Can anyone confirm that this is true? If not/if so, could someone tell me what's going on? A script of mine that ran an AppleScript does't work on Filemader Advanced 9 because it's seeing that the Mac Platform (10.4) is 1.

many thanks.

Not a bug. This is what's reported when you run the function in FM8.5 and later on an Intel Mac.

See Knowledge Base Article #6103.

I've noticed that I cannot import a found set. Instead all records in the table are imported in version 9. This was a problem with Version 7 as well until they released a fix.

Can anyone confirm this problem?

I just tested it to be sure and had no problem importing just the found set.

Michael

I don't recall an importing problem with vs. 7 at all. Anyway, no, vs. 9 imports wonderfully - I've been running 4-5 imports a day for the past month on it (in preparation of a major migration). It rocks!

I've noticed that I cannot import a found set. Instead all records in the table are imported in version 9. This was a problem with Version 7 as well until they released a fix.

This could be a result of having more than one window of the source file open, or not having the source file open (in both cases, all records are imported since a found set can't be determined). I believe this is documented somewhere in the Migration white paper.

here are my bugs in Vista.... Beware if you are using Vista

http://fmforums.com/forum/showtopic.php?tid/189694/

Doing a "Save as...Compressed Copy"(In 9, on vista) Failed to fix corruption in a field index. Can anyone confirm this on any other OS? (possible bug)

Edited August 30, 200718 yr by Guest

I've been kind of scanning this Thread. Without going back and rereading it, I believe that it is about how get a file created in v7, 8. 8.5 to open if v9 says that the file has a problem.

If that is your question, problem, then you don't do the compacted copy in version 9, you go back to the version that the file was created in, and to it there.

Be sure you select "Save a copy as", and then "Compacted copy" (smaller). This should allow version 9 to open it when done.

If on the other hand, the file was created in version 9, then I think we need to know what the Error Message says.

HTH

Lee

"fix corruption in a field index"

Try setting the field definition to "no index", close the file, then open it and turn indexing back on.

How do you know it's a corrupt index?

You talking to me? I didn't ask, or mention anything about Indexing.

Vaughan has a habit of not drilling in on who he's talking to. He's thrown me before as well. Actually, many people make that mistake, myself included sometimes - I think I did it yesterday with Dreamingmind.

But it really would help if respondees either 1) responded to the person they are responding to, ie, "is this the party to whom I am speaking?" Ha ha or 2) used the person's name within their post. It would save a lot of confusion. :wink2:

"Vaughan has a habit of not drilling in on who he's talking to."

It's a habit I'll have to work hard at breaking. :)

I know vaughan, and you are not the only one, you are just the most recent one. It wouldn't hurt my feelings a bit, to see these two buttons go away.

I'll pray for your rehab. LOL

Lee

"I'll pray for your rehab"

I could give this up any time I want. :)

how do ya'll handle get(systemplatform) checks in an Intel Mac / PowerPC and / Windows mixed environment

a little concerned that Intel Macs running the Mac OS on FM 8.5 report the same system as 8.5 on a non-Intel OS.

how is it reconciled?

Case ( Abs ( Get ( SystemPlatform )) = 1; "Mac"; "Windows" )

You talking to me?

Har, har...

I figured Vaughan was doing it on purpose to annoy you! Ah Lee, such an easy mark!

Seriously, of all the deciphering we've got to do to understand what people are saying around here, figuring out what a reply is in reference to is usually the easy part. But our friend LaRetta's advice is good too. I'd add that making wize-cracks at the expense of you guys is always helpful too.

Now what was this thread about again?...Something about finding bugs in FM9? I don't know Lee, I think this was turning more into squashing bugs in FM9. We just keep telling them: "It's not a bug, it's a feature!" :)

I could give this up any time I want.

Ya sure, Mr. 20-posts-a-day!

Maybe when pigs fly... oh yeah ... :qwery:

Hi Ender.

There are NO bugs in v9. There are undocumented features, and things that don't work like Assess do.

Squish, squish, snap, crackle, pot, squish, squish..... What bugs.

:yay:

I know it was a corrupt index because doing a find in a number field (10 digit phone numbers)would not find a value that I knew was there. I have already fixed the index with the method you mentioned. The point was: If Save a compessed copy is the preferred method of stabilizing a file now, and "removes corruption", it did not remove that kind of corroption. From experience, indexing corruption is difficult to find, and you have to fix each field that has it. (I had thought that a save a commressed copy as would have rebuilt the indexes, something a recovery does do.)

I've been kind of scanning this Thread. Without going back and rereading it, I believe that it is about how get a file created in v7, 8. 8.5 to open if v9 says that the file has a problem.

No, this thread was intended to be a a discussion of true "bugs" in ver. 9. Without a doubt there are some. I havn't seen anything Catastophic, but the printing "bugs" are a show stopper for me right now. This thread was intended to explore that and other possible bugs. Filemaker rarely releases any information about "bugs" until there is a fix for them, and I once sent 3 months rebuilding indexes almost dailey, checking my system and solution for problems, and going insane, only to find out when the revision came out that FM knew about an indexing issue but had not informed the public. (I hate surprises)

From the Online Help

Saving a compacted copy

When you save a compacted copy, FileMaker Pro rewrites the entire database, fitting as much data into each block as possible. This reclaims unused space in the file and [color:blue]rebuilds the file's structure. Compacting can be time-consuming if a file is large, and might be best accomplished as an overnight task.

[color:blue]rebuilds the file's structure I believe includes the Indexes.

HTH

Lee

"save as Compressed copy" DID NOT rebuild the index. (at least in 9 on Vista) that is why I posted this here. (possible bug, or at least a behavior that should be known)

Did you try the compacted copy using an earlier version of FileMaker, and then open it in version 9 or your Vista machine?

Not this time. I found an indexing issue, I shut down my server, copied the file to a local drive (on vista) and opened it in 9 without a problem. Saved a copy as...compressed, put the copy on the server, served it, and the index problem was still there. I then had to take it down again in order to rebuild the index in the one field to fix it. I would have thought, as you did, that saving a compressed copy should have rebuilt it, it did not. (I'm currently the only one in my office using 9.)

aholtzapfel,

Maybe its you're field that's corrupt?

How would I be able to tell? Even if it was, shouldn't a "save compressed copy" fix it?

I found the issue with importing records. If I do not switch to the layout of the source data, it imports all records in the table rather than the found set. Thanks for checking on this as I would not have experimented without your confirmation that the feature is working.

If I do not switch to the layout of the source data, it imports all records in the table rather than the found set.

I don't know whether you're saying you "I thought this was true, but it isn't", or "It is a problem"?

I can be on a layout of table 1, and import a found set from table 2 to table 3, without ever leaving the table 1 layout.

It is a little weird though, since when you Commit Records after the Import, where are you commiting them? I think, because you've just imported, FileMaker commits in both the imported into table and the current layout's table (like setting a related field from a parent). But it's a little ambiguous. I will likely continue going to the layouts, just 'cause I've always done so, and it makes no real difference.

Don't know the details yet, but a client on 9 Pro just reported that her computer needed to reboot twice when trying to print out a simple report (with sliding). (And she never did get it printed.)

Is there a fix for this? Or do I need to install 8.5 on her computer?

Also, another computer at the same office printed the report just fine (I think) -- what should I look for on the computer that needed to reboot? Anybody know the conditions of such?

What OS are they running?

Windows XP, I believe, but I'll know more on Tuesday.

You have found, in my mind, the biggest bug in version 9. Filemaker 9 may crash when doing one of the following: Saving to pdf, printing a page range, or printing a layout with sliding objects. I have heard of no fixes, or workarounds. (wait for the revision)

BUG: An ActiveX script call may call the wrong script if Script Folders are used to organize your scripts. (more details in the windows automation forum)