I'm working with a Filemaker script (I'm very inexperienced with Filemaker) and I'm trying to use a double nested loop to accomplish an update on all the portal rows for each record. I'm trying to basically append an 'x' to each portal row's "Desc" field.
It's working except that the inner loop isn't exiting and it just keeps inserting rows into the portal table with 'x' values. When I threw in an early exit I can see the outer loop is working fine. Is "Set Field" supposed to be creating new rows? How can I get this to exit before that happens? I'm aware that I can use "Replace Field Contents" but I'm just teaching myself Filemaker scripting and would like to know why this isn't working. Thanks!
You need to uncheck the option 'Allow creation of records in this table via this relationship' under the details of the relationship on your relationship graph.
With this option checked, any portal created using that relationship has a blank line at the bottom allowing new records to be added. Your 'Set Field' script step is setting that field in the new record line in the portal and therefore creating new records.
Uncheck the option and that blank line disappears and the script will exit.
Your other option, if you want to leave that blank line there, is to amend your script so that it actually works on the related records in their associated table rather than directly on the portal.
Another option would be to use the 'Exit Loop If' script step that tests if a specific field within the portal related record IsEmpty.
Related
I have a Crystal Report with a database command:
The command has a join clause that can be removed and read from a table in the database, because it represents static data. I add this table (called _System) to the database expert:
Now I edit the command to remove the join and columns that reference this table. Since the report fields that depended on these columns are no longer mapped, this causes the Map Fields window to appear:
...which does not have the new table in it. If I cancel out of this I am back to where I originally was. If I hit OK without mapping, all of the unmapped fields on the report are deleted (suffice it to say... I was not expecting this >:( )
I have tried adding links between the command and the new table, and refreshing report parameters, but these have had no effect.
One workaround is to manually replace every field in the report, but this is very labour intensive.
Here is the outline of the command before:
SELECT ACT.Account_Code, ACT.Company, ACT.FName, --etc
STM.CompanyName AS 'DLRName', STM.Address_1 AS 'DLRAddress', STM.City AS 'DlrCity' --etc
FROM Accounts AS ACT
JOIN _System AS STM ON 1 = 1
GROUP BY ACT.Account_Code, ACT.Company, ACT.FName, --etc
STM.CompanyName, STM.Address_1, STM.City --etc
And after:
SELECT ACT.Account_Code, ACT.Company, ACT.FName, --etc
FROM Accounts AS ACT
GROUP BY ACT.Account_Code, ACT.Company, ACT.FName --etc
I have removed the JOIN on the _System table, and all referenced columns.
It appears to not be recognizing your _system table as a new source.
I would :
1) leave your command object SQL unchanged & get the issue worked out with the _System table, then
2) ensure that you are able to establish a join between the command object fields and the _System table fields, and lastly
3) then remap the fields.
Step two I suspect is the source of the problem, as your join condition is "ON 1 = 1" which I assume to mean that you may not have a common key field in both tables.
Note that your original command SQL selects STM.Companyname AS 'DLRName'.
Hence, crystal now know of a field called DLRName, but does not know of a field called CompanyName, hence it cannot make the association between DLRName in the old source, and CompanyName in the new source...
Likewise with the rest of the fields that are being moved from the command object to an attached table. if no name match exists...Crystal cant make the connection. However...it would list all unmatched fields that are on the report, and all unused fields in the recognized data sources, and allow you to specify the matches yourself.
But it does not...which tells me that something has gone wrong with the attempt to attach/open the _System table. Hence..you need to get that worked out first, then make the field adjustments.
If this doesnt get you thru...then show some sample data so I can see how the two tables are relating ( ensure some examples exists where there is a row match from both tables ).
I had the same problem a while ago.
Unfortunately I can't find anything online that helps, or maybe wasn't looking hard enough. I just noticed that in my case, that particular field that isn't showing in the map field dialogue box has nvarchar(max) as its datatype (in view).
I tried to force the datatype with CAST(missingfieldname as nvarchar(20)) as missingfieldname (I did this in the view), and voila, it magically appears in the map field dialogue box.
It seems that field mapping dialogue box aren't showing fields with blob texts.
I know this question was asked 4 years ago. But hopefully, this comment could help future solution seekers regarding this absurd and weird problem. I just got lucky seeing what's unique about that particular missing field.
How can I insert a new record to another table that is related to the field im currently inputting data into without using a portal? Say that it is a dropdown button that has a value list from another table, but the record Im going to enter is not yet in that table so I am just going to type it. If it is a new record then it should be added to the other table for future use.
One technique is to create a script to do the record addition. You can then use a script trigger on the field or a button to call the script.
For example, let's assume that you have an Invoices table and a Line Items table, which is linked by this relationship:
Invoices::ID -----< LineItems::InvoiceID
You could create a script Make Line Item For Invoice ( InvoiceID ), and pass the Invoice::ID value as a script parameter.
The Make Line Item For Invoice ( InvoiceID ) might look something like this:
New Window [Name: "Create Line Item"]
Go to Layout ["Line Item Layout"]
New Record/Request
Set Field [LineItems::InvoiceID; Get ( ScriptParameter )]
Close Window [Name: "Create Line Item"; Current file]
It wouldn't be to hard, once you've got that working, to modify the script to take additional parameters and use them to set multiple fields in the new record.
You can fake it by making a very small portal (i.e. make it 1x1 pixel),
Then you can use the portal way: give to portal an object name, then when you want to add the record make Go to object [portal name], then Go to portal row with Last set and just put in the value (just make sure you have the Add option checked in the relationship)
I want a user to be able to do a search in the layout/table "Cages" and then click a button to run a script that will create a new record in a table called "CagesProtocolLineHistory" for each record in the found set.
Below is what I have so far which almost works but on go to original layout line it doesn't go to the next record, it goes to a record near the end. I.e., it's skipping some records.
Yes, Go to Record[ first ] before the loop will ensure that all records are copied. Otherwise, if the script starts at some record other than first, it will skip all records before this.
A couple of notes: FileMaker string comparison is case-insensitive by default, so you don't need to use Upper() here. Also, in most cases it's simpler not to copy all data through variables, but pass a single key and copy other data via lookups.
You could do this in a three step: search for the "yes"s in a new window; export the record ids (passed params) to a local temp file, and reimport the ids into the child table.
I have quite the request. A developer created our database that has multiple Layouts with a relationship tree that is very messy. Had another developer come in, take a look at it, he said that it would be too time consuming and painful to deconstruct our system, consider creating a script for now so that you can work around it until it can be fixed. Here's the dilemma: I've got information on one page that is supposed to reference information on a number of different pages utilizing tabs and portals. However, all the information is linked to a username. This username is not static/serialized or what have you. Therefore, if the issue is not caught right away a great deal of information can be linked to this person's 'page'. If the name is incorrect and someone tries to alter the username even slightly, it breaks that relationship and starts a new one. The information does not disappear, but it is basically sitting in limbo somewhere until you change the name back to the original. I've actually tried exporting the information, changing the information that doesn't match, i.e. changing a name from Jon.Smith to John.Smith, and then importing the information to a new 'page' for that person with unsuccessful results. Which brings me to my question, is a script going to be able to fix this problem? Likewise, are there any suggestions to how to create this script? I apologize, but I have very little experience with DataBase management at all, and am not sure why this project fell upon me. Any help would be GREATLY appreciated.
Well, as a general answer, just about anything that a user can do in FileMaker (and by user, I mean non-developer, so activities such as defining the database structure, writing scripts, etc., are excluded) can be scripted. So if you're able to "solve" the problem by resetting a field's value, for example, then, yes, a script can do that.
Regarding your specific trouble, a script probably doesn't need to export the records, but could reset the values for the field within FileMaker. This could be done either by looping through the records that need to be changed or by using the Replace Field Contents script step. So a script could do something like this:
Go to Layout[MyLayout] // Go to a layout that is attached to the table you need to search.
Perform Find[Restore] // Restore a find that will show the records you need to change.
Replace Field Contents[Table::Field; "New Value"]
Offering more advice than this would require actually seeing the database and understanding more about your specific needs.
wchsTech4, you are in luck because your problem is easy to fix. You don't even need a script.
BACK UP YOUR FILE(S) FIRST. Then:
1) Create two new fields:
id (person table)
Options for id: Auto-enter serial number
person_id (the table related to person)
2) Generate serial numbers for the new id field in the person table.
Navigate to the person layout.
'Records' > 'Show all records'
Click in the id field and select 'Records' > 'Replace field contents.'
Choose 'Replace with serial numbers' and accept the defaults. Be sure to check the box to update your next serial number.
3) Place the serial numbers you just generated in the related table.
Navigate to the related layout.
'Records' > 'Show all records'
Click in the person_id field and select 'Records' > 'Replace field contents.'
Choose 'Specify' next to 'Replace with calculated results.'
In the drop down on the top left, select the related person table.
Double click the id field (your calculation should be person::id, with person replaced with the name of your table).
Click 'OK' and then 'Replace.'
4) Change the relationship.
Select 'File' > 'Manage' > 'Database.'
Navigate to the relationship tab.
Change the relationship from being based on name to id.
5) Test everything. Should work.
There is a chance that your related records are being created in such a manner that you also need to modify a script, website, or something else not mentioned here to have your fix work going forward. That is important to investigate.
I have a FileMaker script which calculates a value. I have 1 record from table A from which a relation points to n records of table B. What is the best way to set B::Field to this value for each of these n related records?
Doing Set Field [B::Field; $Value] will only set the value of the first of the n related records. What works however is the following:
Go to Related Record [Show only related records; From table: "B"; Using layout: "B_layout" (B)]
Loop
Set Field [B::Field; $Value]
Go To Record/Request/Page [Next; Exit after last]
End Loop
Go to Layout [original layout]
Is there a better way to accomplish this? I dislike the fact that in order to set some value (model) programmatically (controller), I have to create a layout (view) and switch to it, even though the user is not supposed to notice anything like a changing view.
FileMaker always was primarily an end-user tool, so all its scripts are more like macros that repeat user actions. It nowhere near as flexible as programmer-oriented environments. To go to another layout is, actually, a standard method to manipulate related values. You would have to do this anyway if you, say, want to duplicate a related record or print a report.
So:
Your script is quite good, except that you can use the Replace Field Contents script step. Also add Freeze Window script step in the beginning; it will prevent the screen from updating.
If you have a portal to the related table, you may loop over portal rows.
FileMaker plug-in API can execute SQL and there are some plug-ins that expose this functionality. So if you really want, this is also an option.
I myself would prefer the first variant.
Loop through a Portal of Related Records
Looping through a portal that has the related records and setting the field has a couple of advantages over either Replace or Go To Record, Set Field Loop.
You don't have to leave the layout. The portal can be hidden or place off screen if it isn't already on the layout.
You can do it transactionally. IE you can make sure that either all the records get edited or none of them do. This is important since in a multi-user networked solution, records may not always be editable. Neither replace or looping through the records without a portal is transaction safe.
Here is some info on FileMaker transactions.
You can loop through a portal using Go To Portal Row. Like so:
Go To Portal Row [First]
Loop
Set Field [B::Field; $Value]
Go To Portal Row [Next; Exit after last]
End Loop
It depends on what you're using the value for. If you need to hard wire a certain field, then it doesn't sound like you've got a very normalised data structure. The simplest way would be a calculation in TableB instead of a stored field, or if this is something that is stored, could it be a lookup field instead that is set on record creation?
What is the field in TableB being used for and how?