bankmann

Extremely late reply.... If you have access to a PDF printer driver on Windows, you can do the same there. Works like a charm! : Bankmann

Peach Pit Press has a number of very good beginner books on FileMaker: http://www.peachpit.com/search/index.asp...;imageField.y=0 Best of luck! Bankmann

Uhm... as I had this 'problem' because I jump back and forth between Mac OS X and Windows, and the Mac version retains text formatting, I made use of a very simple script. The script cuts contents of the field, exits the field (commit in FM7), and then pastes the text back with no formatting. Like so (FM7 style) Cut[select; <Field reference>] Commit Records/Requests[] Paste[select; No Style; <Field reference>] Commit Records/Requests[] Nothing fancy, but works like a charm. Bankmann

I tried the trimmed version of the database on Windows with version 7.0v2 before I upgraded to version 7.0v3 there. It seems trimming the database design has had much more effect than the upgrade itself; I hardly notice any difference in performance between the two FM versions (Something I did notice on Mac OS X.). I do, however, have a much more responsive database. I'm still bothered with slow drop downs/pop ups and type-ahead, but feel working with the database is a lot better. I haven't noticed any of the other problems mentioned earlier with version 7.0v3 yet. Fenton, I'll be fooling around with your suggestions for the search functionality this weekend, I think. Thanx for input! Bankmann

Uhm.... FileMaker just crashed on me when I aborted an edit value list dialog... Now, that's funny, version 7 doesn't seem to complain about files being closed improperly, but does perform a scan for unused blocks... Bankmann

I think can confirm improvement in version 7.0v3. I find FileMaker much more responsive, and it seems calculations are run much more intelligently (on exit record). I seem to have no more problems with drop down/pop up or type-ahead. Creating a new record takes a bit, though. I haven't tried the upgrade on Windows, yet. Bankmann

I've just updated to version 7.0v3, and I'm seeing improvements. Mostly with drop downs/pop ups and type-ahead. I haven't done a lot yet, so this sort of just a first impression. I think I can see more clearly that the remaining sluggishness has to do with my own design. Your input have given me good pointers. I'll be trying out the tip on handling serials shortly. Yes, I do make use of self-relationships. But I've found a portal listing in such a large database to be painfully slow. (I just haven't gotten around to remove this portal and the automatically inserted checkmark it uses.) The script searching for duplicates is sort of long, and fairly unsophisticated. Basically, it sorts by title, and then compares one article with the next, going through all articles from the first to the last. Each time duplicates are found, the article serials and titles are logged. I've also complemented this script with a step checkmarking the record. After the check for duplicates, a search lists the duplicate records, and I can quickly go through them. I'm not sure how to make use of search in combination with a global field and scripting, but it sounds lik a good alternative. Given the size of the database, and the rate of its growth, I'm all for trimming it down to an acceptable size. As for size calculations; both fields are on the 'working' view, providing visual feedback to the user. I know it's not absolutely accurate; it just gives a fair idea of the main field's and the record's sizes. The main field size calculation was added because of previous FileMaker versions' restrictive capabilities. The record size calculation is just a luxury experiment. I'm just disappointed overall performance got to be so bad in version 7. As I mentioned, I've upgraded to version 7.0v3, and the improvements are quite noticeable, at least so far. Enough to make be try redesigning a bit to see what I can get out of it, at least. Thanx for the input! Bankmann

I guess I should clearify a few point about my conversion experiment. I did this test with a fairly simple research article database. All it does is to store news articles. When a record is created, the following happens (or is supposed to, anyway) 1) Serialnumber, creation date are automatically entered. 2) The highest serialnumber is calculated in a hidden field. (This runs through the whole database, obviously, and takes time. Definitely a point for redesign. But it is a function I need for maintenance.) 3) Checkmark (used in functions for weeding out duplicates or empty records) is automatically entered. 2) Value list pop up give user choice of topic. 3) User enters text/copied text and pictures, enters source information (source, publishing date), and comments, if needed. 4) Two easy, but I guess potentially 'heavy' calculations takes place whenever user exits a field: (1) For ease of use, I use a calculation field to combine all the other text fields, so that I can perform a free text search. (It's a function I don't use often, but feel I need. I realise it's also a reason for the database's size.) (2) To keep a mental track of usage, I calculate the content size of the main article text field, and also of all data fields comined (including blobs). The latter calculation could perhaps be a source of some of the sluggishness? The value lists (only two) are built via relationships to an external resource file I use with several other databases. Seemed like a good idea at the time. I think the database is simple in design, so the conversion shouldn't really have to be the source of my problems. If my computers are too slow or weak to run FM7, then I really don't have much choice. I don't have the budget at work to upgrade just for one program, nor can I afford a brand new Macintosh at home (wouldn't want a new PC there...). So, even if FM7 promises a lot, it's been a waste of my money? I haven't even dared try a conversion on my asset management solution... Bankmann

I've just tried converting my largest database (ca. 11.500 records/330MB), and I'm beginning to see what version 7 is worth. And disappointingly, that doesn't seem to be a lot... I run FileMaker on the following systems: 1) Mac os X 10.3.5 (Panther) on G4/450MHz DP, 1GB RAM, ATI Rage128 Pro/16MB 2) Windows 2000 Professional with SP4 on Intel Pentium III Coppermine/1GHz, 512MB RAM, onboard GPU (Intel 82810E) With version 7 I've noticed: 1) File-bloating; converted files (from *.fp5 to *.fp7) seems to grow to an average rate of 40%, in some some cases even more. A 350MB file bloated up to 520MB on conversion. After compacting it, it was still 45MB larger than the original (395MB). A 5,3MB file bloated to 8,3MB. 2) Connection to other files now has to be defined (?) 3) Pop-up/drop-down value lists are now extremely slow You can now actually start typing in a field before the list even begins to show, and the text typed is not reflected by chosen value (none) This is not constant, but pervasive (ca 80 - 90%), and tied in with a general sluggishness. I think this in one case is because a calculation field citing the maximum value of the serial number field takes too long time to finish, when creating a new record. (Sometimes, even a progress bar appears.) But pop-up lists are slow to appear even when just working in a record. 4) Once a value has been chosen, it's no longer possible to continue a slide down/up the value list (in the pop-u/drop-down). If the chosen value is incorrect, you need another click; to hold and chose new value doesn't work. 5) Entering a double letter (like 'ff') too fast (meaning 'at ordinary or slower speed') will not highlight a value beginning with a double letter, just a value beginning with a single letter; while entering different letters to make a choice works. 6) Entering double letters makes highlight jump past value beginning with two identical letters, highlighting the next valuebeginning with the same letter. 7) On conversion to new format I found that an overwhelming number of records' serialnumber had been changed 8) Text-justification-bug (most noticeable on Mac OS X); spreads letters out in a field, making text difficult to read and edit (The font-smoothing blur-bug was fixed with 7.0v2) 9) The keyboard shortcut-changes made in version 6 have not been corrected (are no longer logical) 10) Window-flickering when entering/editing data (gives an impression of sluggishness) 11) There is an overal increased sluggishness, that, combined with the slowness of dropdowns and the languid screen/window refresh rate, makes it difficult to work fast and effectively; if the user dosn't wait for the system to keep up, data will be entered in the wrong fields. As FileMaker saves data dynamically, offering no undo-function of entered data, this is a recipe for impending disaster. 12) The visual feedback on saving large files (Save as.../Compact) (330MB) is too poor. It takes several minutes before a progress bar appears. The system seems to think FileMaker is hanging during a save operation, and CPU load hits the roof. I've enlarged the file cache to its maximum (256MB), but without any effect. 13) Import is slower, and older files must be opened and converted first. 14) The Mac OS version still doesn't support scroll-wheel mice. Frankly, I've conluded that version 7 i impossible to work comfortably with. I have to backpedal to version 6. Does anyone have any good advice on how to do this, since version 6 obviously doesn't support the verion 7 format? (I've added records to the bases after conversion.) Bankmann

Hi, Ray! Nope, I don't mind relations at all. And as I read your posting, I realized you had a very good point. In fact, as far as the movie database goes, you've probably solved my problem. Appreciate it! ;-) However, as my asset management project goes, things become a bit more complicated. And this is really where the field multiplication horror comes in. The whole solution consists of several database files. An interesting problem to solve, was how to build an dynamic/automatic IP configuration 'overview'. Especially since I needed machines to show in the correct subnet. (I also wanted to be able to do IP related calculations - although this hasn't been put in, yet.) I accomplished this by splitting the IP address into its four octets; one per field; and just stringing the fields together on the layout. (I have calculations putting the address together in the 'background', as part of how figure out which machine belongs to which subnet.) The problem is that some machines; most notably servers; often have more than one network card. Now, smart as I though I was, I made the octet fields repeating, to allow for NIC1, NIC2 (and so on). And the same problem crops up; the machine will show in the right subnet, but the wrong IP address will be listed (The calculation that 'reassembles' the whole address is (as needs be) also repeating.), because the first repetition gets picked. Which is why I was hoping there could be a way to make a caclulation that would 'link' two repetitions in different fields. Bankmann

Hi! I've read elsewhere in this forum how to avoid this rather annoying problem. However, following the advice not to use repeating fields with relations won't help me; that would mean creating a nightmarish mesh of up to or above a hundred extra fields. Yikes! My problem relates to a couple of projects. I'll use the easiest one for example. I have a multi part movie database, to keep account of my collection. The main db has (amongst others) 2 layouts with repeating fields linked to different related db-files. One is a role/character and actor list; (Rep.field Role/Character) (Rep.field Actor) [Role/Character] [Actor] [Role/Character] [Actor] [Role/Character] [Actor] [Role/Character] [Actor] (and so on...) The other is a crew/function list; (Rep.field CrewFunction) (Rep.field CrewPerson) [CrewFunction] [CrewPerson] [CrewFunction] [CrewPerson] [CrewFunction] [CrewPerson] [CrewFunction] [CrewPerson] (and so on...) The clue here, is that I want to be able, under any given actor (in the actor db) or crew member (in the crew db) to list their 'achievements'. The film shows up, no problem, but role/character or function shows up whatever it says in the first repetition; which is more or less almost always wrong, of course. I know I could turn the repeating field strategy around a little, using the first repetition for Name and the next for Function (and so on), for example, but this would clash with the automatic value lists linked to some of these fields. So what I really need is to be able to 'pair repetitions off'. Like: [Actor_3_in_Repetition_10] pairs off with [Role_9_in_Repetition_10]. Does anybody have an idea how to do this? Bankmann

If you use the AppleScript Editor on the Mac, and make it record your actions, while copying/opening/printing the pdf, you might get usefull hints about which commands to use for your script. (Beware, however, a recording will contain a lot you really do not want to keep...) Bankmann