Henk Muller

Dear Syjay, Some time ago I read the following (can't remember where it was, I copied from an email I have send to someone who had the same problem) There is a post in the FileMaker section that identifies a problem running FileMaker Pro 5.0 on new Dell computers pre-installed with Windows 2000. I had a support call from a customer yesterday that confirms this problem also applies to FileMaker Runtime 5.0 solutions. If you go to the start menu -> Program Files you should see a Yamaha-XG Synth program group (or something similar). Open that and uninstall. FileMaker will then work correctly. This problem does not seem to affect Dell computers that have been upgraded to Win2K from Win98 or NT - only when Win2K has been pre-installed on a new Dell machine. Hope this helps, Henk

I tried ALT-0128 (Win98). This worked in FileMaker Pro 5. I've tested it with TrueType fonts only: Verdana, Arial, Times New Roman. According to "Special Characters" it should be Ctrl-2, but this didn't work at all. Hope this helps, Henk

quote: Originally posted by LiveOak: The best solution is to purchase full copies of FM and network the users. As an option, give each user a unique starting number or prefix "AB", "AC", "AD", etc. The prefix might be better, as overlap of numbers can occur. Make sure on import that the update box is not checked. -bd In addition to my reply: Some of the users are asking for a network version. Can you give me some advice what I should be aware of in distributing a network version. I'm aware of the need for the user to buy as many licenses for FMPro as they have workstations, how they should install this and set up the network. But what are the consequences for my database. I read in a newsgroup about the use of global fields in a shared database (that they are only updated in the database if changed by the host). So I have to check the use of global fields in my database. Are there any other differences between standalone solutions and network versions?

quote: Originally posted by john.daly: I had a similar problem with a runtime version used by over 70 individuals all in different locations and with no possibility of networking. They also add ther own records to the database. The way I overcame it was to forget about a unique ID # and in my case producing a unique field consisting of the Company Name and the Postcode combined. If however you just want to distribute a new version of the database without any data in it, then the user can just import the data from the old version (or you could provide a script to do it) with Perform Auto Enter left unchecked so the existing unique ID's will be preserved. Don't know if this is any help. Thank you for your response. I think that my solution is different from yours in that I need the unique ID # in a one-to-may relationship. For a better understanding. My main database contains about 200 fields and generates a report per record of 9 pages. I don't know the proper term in english, but the report is about estimating a house's value. Each record in the main database might be related to one to three pictures of the house in the child database and a corresponding text field. So I need a unique ID # for each record in the main database. For the second part of your answer please read my answer to LiveOaks reply.

Thank you, LiveOak , for your quick response. From the first part of your answer I understand I was not clear enough. The users of my solution are not connected to each other in any way, they live all over the country and I even don't know them personnally. So the prefix in the ID# field is fixed. I understand that the checkbox on importing should be unchecked. But I still don't understand what happens after importing the 'old' records into the new database. The auto-enter serials in the previous version starts at "0001", incremented by 1 for each new record. Say somebody has made 6 records in the previous version. So the unique ID's are: "AB-0001", "AB-0002"...."AB-0006". The auto-enter serial in the updated database starts with "1001", the ID field for the first record will be "AB-1001". After importing the six records from the previous version and making one new record, what will be the ID-fields of the first seven records? That's my first question. The second one is: Is there a better way to calculate a unique ID#? The first update was after two months after the original release. So I'm quite sure there is no user who already made 1000 records. But what if the next update will be after six month? How many records can a user make in that time? As I said I don't know the users. I hope you understand what my real question is.

What is the proper way to set up an unique ID# field that is used in a relationship, especially with regards to importing records into an updates file? I'll try to explain this. I have a main database with a text field "serial" [auto-entered serial number (starting with "0001", step 1)]. There is a calculated field (text, "AB-" & serial). This field is used to create a relationship with a child database. This works fine. This solution is used by several individual users, I mean they are not networked (it's a runtime version). Now I make some changes and fixed some errors in the main database. I want to distribute this "update" to the users. But how to prevent duplicate ID numbers after importing and keeping the relationship between the main database and the child file?

I just moved all the files to the Macintosh platform and look: all the pages of the "blanc report" printed well! This points to a problem with Windows98 and NT, I think. But it's still no solution to my problem!

I created a solution in FMPro 5 which is bound to a runtime solution for Windows and Macintosh users. The aim of the solution is printing a report of one record (about 200 fields). Because all the fields are set to sliding and I want to avoid page breaks in a field, I created 9 layouts for the report (each for one page). My users also can print an "empty report" - a form they can fill in on site. This empty report is on one layout. The "questions" are static text, for the "answers" I defined one global field [text] that is repeated on the form with different formatting (radio buttons, check boxes, plain text fields with base lines), no sliding. This worked fine, except that two users reported that only page one to six from the "empty report" were printed, page seven to eleven only showed header en footer and an empty body. The preview was fine! Now that I changed this empty report for an update of the solution, I encountered the same problem. The only thing I did was changing the line spacing to 12 points so that the report fits in 10 pages. I couldn't figure out what was the cause of my problem. At last I made a totally new layout, replaced the global field with dotted lines, squares and circles and plain text. Now there is no field at all on the "empty report", it's all plain text. Now all the body-parts of the ten pages print well, except on page 8 where the printout shows some radio buttons that where initially on page 3 but are not on my layout anymore! From page 7 on, the body text prints into the footer and into the header of the next page, i.e. the body text of page 8 starts in the footer of page 7, continues in the header of page 8 and starts again in the body of page 8 and so on. I tried different (PostScript)printers: Xerox DocuTech, Oce 3165 Network Copier, Canon CLC 1000). I'm developing the solution on a Windows 98 machine (256 MB RAM, so I don't think it's a memory related problem). Who can help? Henk

quote: Originally posted by Vaughan: Any time I see a database with hundreds of fields in it, I wonder if the data structure needs revising. Think how much easier it would be to print a database with 200 records and one field on each... Thank you for your suggestion, Vaughan. But I think it's not an answer to my question. The problem is not in the report with the 200 fields on it, but in a report without any fields. Just plain text! Have you ever encountered such a problem? Henk