I have a customer list in a drop down. The drop down field has an On Save script trigger which then performs a find in the same layout for the selected customer. The drop down field is configured to 'go to next object using' return.
There is also an On Record Load trigger on the layout which pops up with a dialog if the customer's Attention field is populated.
This all works fine unless I utilise the option to save the drop down field with the enter button. It ends up looking like this, with the white background. Once the user clicks OK the layout 'appears'.
All files/tables in this discussion are fmp12 using FM 17 and both files are opened when initiating the app. "logging" is opened as the primary file and "claims" is opened as an external data source.
I have a table called "newclaim" in "logging" which contains mailing address information including a USPS zip code. I have a table called "lu_ZipCode" in "claims". There is a relationship set between "newclaim" and "zipcode" on a field called "COID" (company ID). This field is automatically populated in both tables with "DCSI". This is an old method (used in Fm6) of establishing a simple relationship so that global fields can be used to pass parameters into scripts for zip code lookup and verification.
In the parent script (in "logging") I set the related field "lu_ZipCode::_gZipCode" with (for ex) "12345" with the intent of calling a subscript in "claims" then using "12345" to do the lookup. However when the subscript is called the "_gZipCode" field is empty. As a workaround I called the subscript passing the "12345" as a parameter which of course works as one may expect. After setting the parameter to a local variable in the subscript I'm able to do the lookup then populate the global fields "lu_ZipCode::_gCity" and "lu_ZipCode::_gState" while still in the "claims" file. Yep, sure enough when I go back to the parent file the global fields I just populated are empty.
It's worth pointing out here that prior to yesterday "zipcode" was a separate file and the methods described above worked like a charm. This effort is being put forth to consolidate this old FM6 solution with 40+ files into just a few files. I imported "zipcode" into the "claims" file then copied and modified the scripts anticipating that this would be a quick little project to get rid of one more file.
I know there are better methods (ie JSON) to get this done and I will probably go that route. At the same time I'm left scratching my head on why this tried and true method doesn't work. Why would global fields I can populate from one side of the relationship not be populated when viewed from the other side?
By Matt Navarre
Announcing fmSearchResults 5. This latest download delivers new features with simple implementation. And it's free!
fmSearchResults 5 adds fast, multi-table searching to your FileMaker solutions by importing a few scripts and pasting a simple search field on to your layouts. It feels like the type of Google search that all your users are already familiar with, and it’s far more powerful than FileMaker’s Quickfind feature, because it searches across multiple tables and has data-type awareness.
Read more about the new features and download it now!
Implementation is so simple, watch me do it 5 minutes (and 12 seconds).
I have a database that we use to update our website inventory. A few years ago we began offering customized merchandise that gets dropshipped direct from suppliers. Suppliers give us data feed files with their inventory levels, pricing, etc. and this file manipulates the data. It takes our current web database, compares values and exports those products with their updated values.
Importing the data and exporting used to take less than hour but now it takes several since the size of the web database has grown and the number of suppliers has grown. Everything is automated through scripts. In the main table (web database), the proposed quantities, pricing, leadtime, variations, etc. all use unstored calculated fields to determine the new value. I then have a separate field which is used to flag items that need updating. The major bottleneck of the entire process is the searching of this field. It can take sometimes over an hour to search this field. Other steps like exporting the changes can take a while, too.
I have done some things to optimize the database but it still seems that these unstored calc fields are what is dragging everything down. I have tried replacing some of those calc fields with text/num fields with "replace field contents" script steps (or auto entry) but it does not seem to make a difference because of the indexing. The database is not hosted or shared and my computer has decent specs with an SSD HD. I've got a simplified design chart attached for reference.
I am not sure that this is what comes with a large complex database file or if my design is flawed. The only two things I can think to try to reduce the processing time is:
1) Rewrite the scripts to update the supplier/inventory table records instead of replacing the records fresh each time.
2) Use a looped set field script to set the "change flag" field and/or the other updated price/qty/etc fields
Any thoughts or advice is much appreciated.
at first I was struggling to find some data which I knew was present and couldn't figure out why...
Data in text field (real example):
A 0111 B0111 B0116 TZ0113 [...] Search string (quotes not part of search):
"0111" finds "A 0111" but not "B0111" etc.
But I figured out how to adjust my search so FileMaker will pick up these records accordingly by wrapping it in stars like *TERM* so it performs partial matching:
"*0111*" finds "A 0111" and "B0111"
Now my question is: How can make this the standard search mode / feature without extensively writing scripts for every layout?
I am working with a search layout which includes a lot of fields and I would like to just be able to set "partial search" as default for selected fields or – if that's not possible – for all fields on the search layout, knowing that this can be achieved by using a search script which wraps every input in "*" but that seems kind of over the top.
Thanks for your input!