Bob White

Actually, I doubt that the file is toast. If I open the file with FM9 or with FM9 Advanced, it comes up with the Fields listing in the usual manner (a few seconds churn then the list appears) and export is perfectly normal. Data updates just fine. All scripts work just fine. I am reasonably sure that if I go back to working with this file on a daily basis using 9 instead of 10, I wouldn't need to have this conversation. I have a theory that goes like this: Buried deep in each FMP file, I'm thinking that there has to be a hidden text file or perhaps even a FMP file within the visible FMP file. Whichever it is, there has to be something that stores the all the field names with the set characteristics, what is switched on or off, etc... All files of any kind have headers. Since my condition happens immediately with FMP 10, I am thinking that there is something in the header of this one single file that FMP 10 is finding disagreeable to the point that it cannot get past it. Do you think that holds water? And, if so, any ideas for repair?

I did not migrate from 7 to 10. I migrated from 4 or 5 to 5.5 to 6 to 7 to 8 to 8.5 to 9 to 10 with this database. I don't know about new recovery functions in 10 but yes I have tried recovery. And I have done save as- compact and save as - clone. I should have said so earlier. I also didn't say that this affects anything that needs to consult the fields defs such as doing an export.

The database in question is not overly large.. less than 2,000 records, about 50 fields and 40 scripts. No outside data sources; no web involved, etc.. Basically used on one Mac to track membership and services including invoicing for a Mac user group. It was originally written in FM Pro 4 or 5 and has migrated up the ladder without any problems. With one exception, it continues to work just fine in FM Pro 10. The exception is when one chooses Database in the File>Manage function. Accounts.., Value Lists, Layouts, Scripts and External Data all pop up immediately. But choosing Database brings this database to its knees. Making that choice results in the good old spinning ball interspersed with the command/dot. If the Forced Quit Applications window is open, one can see it cycling in and out of Not Responding. Up until today, it would eventually produce the Manage Database window taking on average several minutes to do so. As of today, no luck. I let it run for 30 minutes with no open. Other notes: There are no FM Pro 10 Only features in said database. It is only happening with this particular database. In all of the roughly two dozen active databases I'm running with FM Pro 10, this window opens right away. In this particular database, if I open it in FM Pro 9, the Manage Database window opens quickly (5 - 10 seconds). Before trying it in 9, I was thinking that maybe the Field listing (assuming there is a file buried deep in FM Pro) was corrupted. That was just a guess on my part. Can anyone shed any light on what may be ailing this file and how I might fix it? TIA to anyone who can help.

The mini has the smaller 2.5 inch drive like the PowerBook laptops. A member of our Mac user group set up a mini as a server for his home system of several Macs. The hard drive failed after about 8 months. For servers, it is better to stick with the standard 3.5 inch drives. (Note: This was a G5 mini.)

I don't know if this works generally. I used the pre-built Google map item and checked the Allow Interaction. I have found that I go someplace else in the Viewer window that a right-click gives a short popup menu with two choices: Back and Reload.

You might want to look at MacFixit. I noticed something regarding some users being unable to reestablish their local networks. I didn't read it as I was looking for something else. You might not have a FileMaker problem.

Finds and scripts with Finds seem to be sluggish.. but then I've only opened a couple small databases since installing Tiger last night.

Actually, my iBook 600Mhz (640MB RAM) runs better and quicker in Panther than it did in Jaguar or 10.1. Panther uses roughly 190 MB of RAM to run on most machines. With 384 MB, you should be quite OK. FMP7 is just as quick as on my desktop G4. But I don't have any huge databases, either.

Ender: Darn it! In rereading what I typed, it appears that I forgot to say what problem this was causing. The problem is that the user gets phone calls and emails AND needs to know when the last update was in order to respond correctly (and the update that the user cares about is only a single field). The script was bringing this field's date to the current date in all records, thus destroying the user's ability to fully respond. Live Oak: I was not using the today function. That is why I consider it strange that conversion wrote the script that I mentioned. Fenton and transpower: Good ideas all but I don't need them here. Thanks for the comments.

Just sharing a problem solution as I could not find anything on the subject here in the Forums. I had converted a small database from 6 to 7 which had time and date fields to record the time on a single record whenever there was an update of any data in that record. When I started the database in 7 for the first time, the date and time was updated on all 2000+ records. After saying several not so nice words under my breath, I found that FM7 had written the following script and set it to run at startup: # The Today function was removed in FileMaker Pro 7. # The 'Today' field and this script were generated by conversion. # On startup, this script updates the value of the 'Today' field in all records if the date has changed. Set Error Capture [ On ] New Window [ ] Perform Find [ Specified Find Requests: Omit Records; Criteria: RCA Membership::Today: "//" ] [ Restore ] Replace Field Contents [ RCA Membership::Today; Replace with calculation: Get(CurrentDate) ] [ No dialog ] Close Window [ Current Window ] So beware and read those darned conversion reports before starting the database in 7. It works just fine with the field being defined to auto enter only during data entry, so I have no idea why the 7 conversion found it necessary to write a data destroying script. After deleting the script, I ended up having to import the dates from the old 6 file to recover this data.

I have seen such behavior. The cause was that there was an Open File step in a startup script still pointed to a location remote either on the web or the in-house hard wire network AND the file had been moved either to the local machine or a different server. The fix was to edit the Open File step to point to the correct location of the file -- in this case in the local machine.

Considerations that were not presented: What are we comparing to? How are the Mac's currently networked? Is the referenced database on one of the Mac's or is it remote? If remote, what kind of connection -- dial-up, DSL, cable, T1, etc.? How many users are there usually at one time? (Home office gives me a picture of at most 2 or 3 users.) Are you planning to upgrade to OSX soon?

Regarding a few comments back about MS buying FoxPro. As I recall, at the time, what MS really wanted was the at-that-time new-superquick "engine" (Stockton?) that made FoxPro so lightning quick (for that era). As of a couple years ago, that "engine" was alive and well -- driving the corporate version of Outlook! (That was related to me by an Outlook tech engineer in either 1999 or 2000, so I don't know if this is still the case.) Point is that companies don't always buy other companies for their whole product line. Lots of times they buy to get the "missing piece" to finish their own product development. My guess would be that if Apple is supersizing Appleworks to compete with MS Office, then it would be interested in selling a real database (as opposed to the very limited database function in Appleworks). They certainly wouldn't be interested in it for its lightning quick speed!

If you are using the current version of Excel (Office X or Windows 2000 or later), you can tranpose your data into rows in Excel. Highlight the data for one record, choose Paste Special under the Edit menu and highlight a horizontal selection of cells with the same number of cells as your vertical selection. In the Paste Special dialog box, check the Transpose box and click OK. Your data will paste into a row. Of course, this is OK for just a few records. For a thousand, it may be possible to record a Macro in Excel but that is not one of my stronger areas. Another reader possibly can advise about that.

I'm using FMP 6 and OSX 10.2.5 currently. When I upgraded to 5.5 and an older version of OSX, I had this problem with several TrueType fonts. If those particular fonts were present in a layout, I would print a blank page. If I changed the font, the page would print just fine. As you may or may not know, you can store fonts practically anywhere in OSX. By trial and error, I finally figured out that that the guilty fonts were stored in HD>Users>UserName>Library>Fonts. I moved them to HD>System>Fonts and the layouts starting printing just fine. It drove me nuts for a couple weeks. I have run into this problem with several other applications. My theory is that there are driver programmers out there that aren't up to speed on OSX and are still looking for fonts at HD>SystemFolder>Fonts as with previous versions of the MacOS.