SlimJim

Regarding loss of index - I don't know how easy it is but I think this is the first time this has happened to me and I have been using Filemker since Version 2.1. However, 'using' may be the key. I generally make databases for my own use and once they are up and running I only make changes when I want to change the structure. In this case the database was for business use, the company split into two parts and needed to have separate invoice numbering for each of the two parts. So I added a new field to identify which company was issuing the invoice and a new auto-enter based on an additional relationship to determine the invoice number after the company field was populated. I am now certain that this is what caused the problem with indexes. Invoices issued after this change could be found the ones before couldn't.

Missed your post while replying to Inky Phil. I have actually just done the v3 update. I have been thinking back and the only change I can recall making was a modification of the auto-enter calculation on InvoiceNumber and it rather looks as if that was the culprit. Many thanks to both you and Phil for responding so quickly.

No I haven't and that is what was required. Many thanks Phil

A problem which has started in the last week or two. I can no longer find invoices by number. My Invoice numbers are serial numbers, (of number type) starting at 1. When I input a particular number, which I know exists I get back no records. If I put in the find "> 0" which should find all the invoices it only finds the ones in the last two weeks roughly. My first thought was that somehow the numbers had been changed to text so I put in an extra field defined as a calculation GetAsNumber(InvoiceNumber) and then when it had calculated converted it back to a number field. Fnding using this field works as normal. The next step was to replace all the InvoiceNumbers by the numbers in this new field, this made no difference to the finding problem! I checked the validity of the InvoiceNumber field using a script looping through all the records, again no problem. They are all numbers but they still cannot be found. I want to avoid replacing the InvoiceNumber field by the new field as InvoiceNumber is used in numerous places, in relationships, scripts, calculation fields and auto-enters. Can anybody shed any light on this?

I don't know why you are getting the message followed by nothing. If you look in the system folder within your application (or Claris) folder you should see a collection of files of the form fmbmp32.flt where the letters after fm indicate the file extension that the filter is supposed to deal with. In my folder I have filters for bmp, gif, pcx, tiff, cgm, hpgl, pic, wmf, drw, mac, sld. If you right-click the filter file select properties the version tab will tell you what the filter is for, if it is not obvious. jpg is not one of the filters but bmp is, so why you cannot import a bmp file I don't know. Have you applied all the available and appropriate updaters to your version 3?

There is another way which I found by accident. Select the body tab use the fill colour in the status area to set one background, as normal; and use the line colour in the status area to set the alternate background.

The simplest way, I think, is to open a command prompt travel to the directory you are interested in and then issue the command dir /X. That gives you two columns of names (on the right) the first column is the DOS name and the second column is the long filename. If the long file name satisfies 8.3 already then there is no entry in the first column,

Try replacing "Program Files" by the old-fashioned DOS name Progra~1. You will probably have to do the same with other elements of the path which contain spaces.

I'm not sure if I have understood the question correctly but I have made a modification to the auto-enter in your file. Is that the sort of thing you are looking for? LookUpOr2.zip

If you always round up then you can introduce rounding errors. For example 1.5 cents rounds up to 2 cents, 2.5 cents rounds up to 3 cents. Add the two together and you find 4 cents becoming 5 cents. Rounding error can be reduced by leaving rounding until you have completed all other operations but the practice of always rounding up at .5 leads to inevitable errors. To reduce the effect of this simple rounding error you need to round up half the time and round down half the time and the even/odd choice is the common way of doing that. Note that it does not remove the errors it balances the effect.

In File > file options on the open/close tab there is an option to Switch to Layout and a drop-down list of layouts to choose from when you have checked the box.

One method - probably you will see many others before too long. Make a global text field in your table: Small with value "small". Make a second occurrence of the table in question, SMALL say, and then relate the size field in SMALL to the global Small and define SmallCount as an unstored calculation Count(SMALL::size). Copy that for medium and large.

Do the same thing as you do in Access with appropriate changes to reflect the function names in Filemaker. For example suppose you have fields Name, Address1, Address2, City, PostalCode then define an unstored calculation field EnvelopeAddress = Name & "¶" & If(IsEmpty(Address1);"";Address1 & "¶") & If(IsEmpty(Address2);"";Address2 & "¶") & City & "¶" & PostalCode I'm assuming Name City and PostalCode are not empty but if they could be do the same calculation for all address lines.

This is not a resolution just a few remarks since you seem to be working on your own here. Your If calculation should return either an abbreviation or nothing so how does it return Alberta? To me that seems to indicate that the If is not being evaluated. So go back a step and check out the Case function. This part of the case is evaluated if the international_Addressing::city_line is empty could the problem be here?

If it is a strictly 13-digit number you could perhaps do a range validation 1 followed by 12 zeroes up to 13 9's

Am I missing the point here? In your portal your are showing the values of 12 fields and you want to create a button which will transfer the 12 fields into a matching set of 12 fields in the main record? Doesn't the following work? Turn one of the fields in the portal into a button. When it is clicked it selects the portal row as a related record and you can then simply transfer the data by a sequence of SetFields SetField(Main::field1;related::field1) ... SetField(Main::field12;related::field12) where related is the name of the table used in the portal.

The field names are very long and that is why this problem has arisen - the FMP standard layout arranges the fields and their labels in two columns, fields on the right with the labels right aligned and the fields left aligned. Because of the length of your fieldnames this has failed to work correctly, if you can your first step should be to change the names of the fields so that they are not so long. If you do that then you need to design the layout to take account of the typical amount of data that will be entered into each field. On the other hand if you want to go with the standard layout design with the existing names and labels, (using more screen space) you could select all the fields - select one of them,press Ctrl+Shift+A - and using the right arrow key move them in a block to the right until they clear the labels. Now select all the labels - select one, press Ctrl+Shift+A - and then right-click. At the bottom of the context menu you will see Arrange. Select that and align right edges. This should give you the standard layout but it will be wider than the screen. However, depending on the data you have to enter this may be OK.

Is the final loop in your script the beginning of a new loop in a bit of script that we cannot see?

Since the look up is based on the temporary match field it will automatically refresh when you change the temporary match field. You need to use an auto-enter which does not change when you delete the contents of the temporary match field. Case( IsEmpty(Fetch::ID); ID; Fetch::ID ) This calculation does nothing to the ID field if there is an empty Fetch::ID and otherwise looks it up. This allows the user to change his/her mind over the choice of temporary match field.

Hi Hociman Let's look at the basic structure of your database. You have a companies table - it should contain an ID number (auto-enter serial is fine) and then whatever details you want to store for a company. Your contacts table should contain two ID numbers - contactID (auto-enter serial is fine) and CompanyID plus whatever details you wish to store about a contact. The relationship between company and contact is matching companyID. If you are looking at a contact layout and you wish to select a company then you will need the CompanyID field somewhere. (There have been lots of discussions as to how to do this so I will suggest a straightforward method and you can read and change if you wish) Make a value list of company ID numbers (show all) and show Comapny Name as a second field. Choose to sort by second field. As you are using v8 you can choose to not show the ID field in the value list. Set up the companyID field with this drop-down list. When you select a company its ID number will go into the field. If you want to see the company name on your layout then put the related field comapny::company name on the layout. This will show up as soon as you have chosen an ID number. If you allow creation of company records via the relationship then leaving the companyID field blank and entering a name in the company name field will create a new company record (you will see its ID number pop up into the companyID field. I have made a few alterations to Daniele's sample to illustrate. Company.zip

From your description of the "symptoms" I would say that the company field in your contact layout is the related company field from the company table, whereas it should be the company field from the contact table. [if you do not check off creation of records then that field cannot be entered which is why the drop-down list disappears; if you allow creation of records then whenever you put company data in that field, by any method, it will create a new company record] Incidentally the relationship matching company to company between company - contact is almost certain to be one - many not one- one.

The or in your quote always evaluates to true (the first statement is true unless LocCurrentRes::Apartment = n/a and then the second statenent is true since n/a is not empty). The problem is in the use of not equal. In order to achieve your aim using "not equal" you must replace the or by and. Alternatively replace the not equal by equal and invert the order of the last two items of the If.

I can see no reason why this script shouldn't do the job. What exactly goes wrong? Have you turned on script debugging and tried monitoring the field values?

There seems to be a lack of response to your question so let me have a go. In order for the ContactId to be populated automatically you have to create the new record in the Quotes table via a portal (or at least via the relationship) in your prospects layout. If you are creating a new quote via a script, for example, by going to a quotes layout and then creating a new record, then it is necessary to grab the contactId from the prospect record you are viewing and insert it into the contactID field in the quotes table.

I believe the Epson LX300 + printer has a Custom paper size available. If you select that and enter the size of your paper that should help.