Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 5818 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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.)

Posted

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)

Posted

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

Posted

"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)

Posted

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

Posted

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.)

Posted

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

Posted

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.

Posted

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.

Posted

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?

Posted

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)

Posted

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)

Posted

I don't know if I'm the only one with these problems, but I have a hard time with object names display. The names stick, as my scripts that use them work properly, but I can't see the name in the object info box. Also I have problems importing images in global container fields when accessing the db on a windows 2003 server via "open remote". The image will display for a while, but eventually gets dumped. The only way around is to import the image using the server itself (running fmp9 on the server and opening the file locally).

Posted

So, it turns out that the problem was with the operating systems, Windows 2000 specifically. FM 9 does not support Windows 2000, and every time the user tried to print, the computer would reboot. I talked to our Filemaker rep, who was surprised that we could even install 9.0 on Windows 2000.

Needless to say, IT is going to be updating everybody's operating systems.

Posted

I take back my last post. IT is now telling me that they're in fact running XP SP2, with all of the latest updates applied. Their computers reboot when they try to print to an HP 4350 (they are using the latest version of the HP print driver).

Anybody have insight?

Posted

Hi All

I'm having a few issues with 9. I have a large filemaker system with 92 tables and tons of relationships etc. It's served up by FMS 8 on Tiger.

I've see two issues so far and both are around relationships and in both cases it works perfectly fine on 8.5

1. I have a drop down list that is filtered with a relationship (several tables down). the drop down is empty from within a portal but fine from the rest of the layout. works in 8.5

2. a repeating calc field uses Extend( Jobs::ganttChartDate ) but in 9 it can't see the value. I had to make a new calc field in the table that looks up Jobs::ganttChartDate and use that in the repeating field for it to work. Again this worked fine in 8.5

Any ideas or am I just being thick ???

Thanks

Posted

"I've see two issues so far and both are around relationships and in both cases it works perfectly fine on 8.5"

The FMP 9.0 Read Me file documents the changes the relationships in FMP 9.0. It's a known issue. It might be the cause of some of your problems.

  • 1 month later...
Posted

Just to add fuel to the digital fire...

I have (at least?) two, very strange bugs in 9.0 Pro Dev (PC):

1) When a user is commanded by FM to create new password while logging into the runtime app for the first time, he or she creates a new password and is then allowed into the solution. Cool.

However...

When the user logs in again _and leaves the Password field blank_, the user can click on the OK button in the Account Name/Password windoid and is allowed into the runtime.

Mind you, at that point in the runtime none of my scripts or functions are enabled so...?

2) Same runtime, but different problem: per a privilege level action, the "user" level people aren't allowed to change the field content in some of the fields. What's strange is, if a logged-in user were to try to change the contents of the field(s) then the standard FM "Your access privileges do not allow..." error message pops up...which is fine except on a different PC--and performing the same action on the same field--the standard FM "This action cannot be performed..." error message appears. So far, on three different PCs we've experienced this problem, however, each one consistently reports the same error message so it's not "flopping" with each login on each machine.

Unfortunately, since it's a proprietary runtime, I can't post it on here for peer review...but if anybody else has had these two bugs, I'd appreciate knowing about it.

  • 2 weeks later...
Posted

I think I found the problem that I mentioned in my previous post: Norton 360 by Symantec. When I removed the software, FileMaker began behaving itself again as well as I was able to download Windows updates again, too. I replaced 360 with Norton's Internet Security and it plays well with FileMaker, so all's right with the world again. ;)

So, just an FYI.

  • 1 year later...
Posted

Not exactly a 'list' of bugs,

but I found this single bug/issue accidentally today. I'm calling it a bug/issue because my colleague on a Mac couldn't duplicate it.

When on Windows XP, Using FM Pro 9 Advanced,

I clicked in a very specific spot (near the top) in the 3-pixel wide side bar that appears while in list-view. My status area was hidden, and regardless of whether or not it was locked, 4 buttons appeared allowing me to change from browse mode to layout/find/preview modes.

This can be reproduced even in a brand new file.

Posted

Can you post a screen shot of the button that appeared?

Thanks.

Posted

It is important to say that NO one of the appearing buttons works ( no way to change Mode ) and that the Browse Mode is always selected.

This topic is 5818 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.