Carlisle

Never mind, I figured it out. I have to do a sort first, and then it works. Duh-OH! Sorry for the trouble

I have a report that is summarized by one field. When I print the report, it is appropriately sorted, by the field value, but the sub summary doesn't appear in the Preview, nor is it printed. Where is it? How do I make it appear in the printed report? Thanks, Carlisle

Thanks again for your help. OK, well here's the idea. I have a project database in which a project consists of creating a bin containing a bunch of samples of a single item that is one of a set of items, making another bin of samples (which may or may not contain the same item that is in a separate bin), or retrieving a sample from one of these bins. So there is a project table, a table of the different items, and a table of bins that is joined to the project table via a join table. Now, when I create a new project, I also sometimes need to create a new bin, which I can do by entering data into one of the bin fields from the projects table; this then creates records in the both the bin table and the join table as long as the record id field in each is an auto-generated value filled on creation. This is what happens in my example when I enter a value in Table 1 in the field Table2::color. But then Table 2:name doesn't look up its value from Table 1:name. (For simplicity, my example is doing its lookup from Table 1, instead of from a 4th table; this doesn't affect the outcome.) Now, this bin obviously also needs to be identified as to contents, that is, which of the items does it contain? I've already identified which item is being used in this project, so I want the new bin to simply look up what this item is when the record is created. But it doesn't. The relationship is valid, in the sense that after the record is created, I can then use a SetField script step to retreive the value, or I can replace the contents via a calculation using the relationship to item via the projects table. But it won't do this as a lookup. In contrast, you *can* look up the correct value if there isn't an intervening join table.

Sure! Here it is. As you can see, the table 1 layout has the field "color" from table 2; entry into this field creates a record in table 2. However, the table 2 field "name" doesn't look up its value from table 1. However, if you create a new record in table 2 that has a value in its "id" field that makes it related to table 1, the lookup will work. Play around with it; you'll see what I mean. Thanks for the help. Test2.fp7.zip

Thanks. I tried that to0, with no luck. For the moment I'm going to the related record and invoking a script that uses setfield and the relationship to plug in the values. It has something to do with using a join table--the same problem occurs in a little 3 table test database that I made.

OK, I'm stumped. I've got a multi-table database. I have 2 tables connected by a join table to allow many-to-many joins between the two. Table 1 has an auto-entered serial number id field as does Table 2; they are joined via Table 3 which has its own serial number field and values for the Table 1 and 2 ids. Table 2 is set to allow creation of records from Table 1 via this relationship. So far, pretty straightforward. I have a layout in Table 1 that displays a field A from Table 2 that allows entry; entering a value into this field in this layout therefore creates a related record in Table 2. So here's the question: I have another field B in Table 2 that is defined as a lookup; it is supposed to look up a value from a field in the related record in Table 1. It isn't looking up the value when the new record is created by entering data in the Table 2 field of the Table 1 layout. Does anybody have any guesses why this might be, and how to make this auto-fill short of using a set field script after the record is created (which is the only solution I've been able to figure out)? Thanks in advance.

Wait a minute. I just tried it again, and now it works. Hmmmm.... (Just in case you are wondering, it was the same script as yesterday, so no, I didn't have any spelling errors!) : Hmmm....I shut down and re-started since yesterday....was that the solution? That's decidedly odd..... Well, if I ever get some time, I'll try tracking it down and post the results.

No spelling errors at all. I can't figure it out, and it's driving me batty! Could it be an OSX-only bug?

I want to use a script to open a different layout in a new window, and I want to define the layout using a script parameter. I can't seem to get it to work. If I do the following: New Window Go to Layout(Layoutname) It works fine. If I simply want to go to a new layout using a script parameter, I can do: Go to Layout(Get(ScriptParameter)) But, if I do: New Window Go to Layout(Get(ScriptParameter)) It doesn't switch the new window to the different layout. Obviously, I'd like to be able to use a script parameter so I don't have to write a new script for every window I want to open. Anybody have any ideas about what gives? Is this a bug, or am I missing something here. Thanks for any and all advice.

If I have a database and assign background colors to different parts, then when viewed in FM the color fills the window in browse mode. However, when viewed via IWP, the background only extends to the limits of the page. How do you get it fill the entire window? Thanks, Carlisle

Hi, I've just started trying to implement a requisition form using IWP. I have some text fields that are lookups to a separate file. When I make a new record directly in FM, the field values lookup properly. When I make a new record via IWP, the lookups don't occur. I'm sure there is something obvious that I'm overlooking, but I need help finding it. Thanks, Carlisle PS I'm also running Tiger (not a choice of operating systems on the FMForums yet). The browser is IE 6 on a Windows machine.

First some background. We have a multiple (>40 tables) file .fm5 database being served by FMserver to a mixed bag of macs and pcs. The server is an XServeG4. Twice in the last couple of months, I've seen some odd and rather frightening behavior: scripts with a "Set Field" step don't work properly. The step "Set Field (othertable::fieldN, fieldA)", instead of setting FieldN in the other table to the value in FieldA in the current table, sets it to a value taken from a different field in the current table. This seems to be function of the client machine, not the server itself, as it behaves quite properly using my own client. It happened with both a Windows client (in that case I reinstalled FM6 on that client, which seemed to fix it) and once with a Mac client. In that case, the Mac client's home directory was on the server. When I had the user log off, then log on from a different machine, it seemed to fix the problem, ie, logging on from the original machine no longer exhibited the behavior. So, does anybody have *any* idea about what gives here? You can see why it might be a scary problem. Most of my data entry people are savvy enough to recognize that a problem is occurring and come to me, but you can bet your life that somebody won't be paying attention some day. I'm guessing it might be some sort of corruption of a local preference file. Should one be replacing those files on a regular basis? I'm stumped. Thanks in advance, Carlisle

Hi Samantha, What's your email address? Anyway, make it $35 and you've got a deal! Carlisle Landel clandel@adelphia.net

I can do this, but limited access users can't enter information in find mode. Full access users can. ANy hints? FileMaker Version: Dev 7 Platform: Mac OS X Panther

A web-shared file doesn't seen to want to enter find mode for users whose access is limited. Any ideas why this is? Curiously enough, the Modify Find button does put it into Find mode, and allows one to enter find criteria. Weird.