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.
Related
So I have a form in Access.![acessform1][1]
Here are form properties
I got this database and have been making adjustments to the other forms. I gave the database back to the user and they reported an issue that this form is not acting properly, and the add order record function is not working anymore.
There's an Add Order Record button on the right side of the form that would usually add the record if the user manually entered input into some of the boxes. The old form you would have control of the values 1/0 for yes/no. You can enter text into the notes boxes.
This functionality doesn't work anymore, and I can't seem to figure out why. The form is identical to the original and no adjustments have been made except to the table that it pulls data from.
So the symptoms are:
User input is not accepted in text boxes.
The find CP functionality works with the drop down and reflects the records accurately but I cannot update the fields.
Also, the fields CP_Ref and Invoice date don't let me enter data anymore.
Also the Add Order Record was giving me an error that The it could not find the record specified, but I since copied the original form back into place and that error went away.
I think functionality wise this button should save the record after a field is updated and should add a new record.
Seems like all the controls are locked on the page.
Here is the query that pulls the data when I click the button that takes me to the Order form.
SELECT DISTINCTROW CPOrders.Cust, Customer.NAME, CPOrders.CP_Ref, CPOrders.Slsman,
CPOrders.Date_opn, CPOrders.CPSmall, CPOrders.InvIssu, CPOrders.InvNo,
CPOrders.InvDate, CPOrders.DueDate, CPOrders.ETADate, CPOrders.Closed,
CPOrders.Cust, CPOrders.Name, CPOrders.BuyerRef, CPOrders.ToCity,
CPOrders.ToState, CPOrders.ToCtry, CPOrders.ToPort, CPOrders.Supplier,
CPOrders.Origin, CPOrders.Product, CPOrders.GradeType, CPOrders.NoUnits,
CPOrders.Pkg, CPOrders.Qty, CPOrders.TotSale, CPOrders.TotCost,
CPOrders.GrMargin, CPOrders.[Sale$/Unit], CPOrders.[Cost$/Unit],
CPOrders.OceanCost, CPOrders.OceanNotes, CPOrders.BLadingDate,
CPOrders.USAPort, CPOrders.FOBCost, CPOrders.FASExportVal,
CPOrders.InlandFrt, CPOrders.CommodCode, CPOrders.Notes,
CPOrders.ProjCust, CPOrders.ProjValue, CPOrders.ContainerNumber,
CPOrders.Vessel, Customer.TERMS
FROM Customer INNER JOIN CPOrders ON Customer.[CUST_#] = CPOrders.Cust
ORDER BY CPOrders.CP_Ref;
I ended up checking several locations for the answer to this.
What it ended up being was a primary key issue.
Essentially when I got the updated database I put them into new tables, effectively destroying the dependencies, relationships, and established keys.
I reverted back to the old tables and found out the form worked properly.
The issue ultimately was that the primary keys were not defined as needed for the table to be updated.
I have a specific question regarding the utilization of three tables in a database. Table 1 is called Personnel, and lists the names of the staff.
Tables 2 and 3 are identical, just listing two different types of overtime (long and short), along with the hours of the OT, Date of the OT, and Assigned to/Picked fields that are empty.
Here is the idea, I just dont know how to implement it. I would like to create a form for people to enter their OT picks, then automatically move to the next person on the list. So Rich Riphon, as an example, would be up first, would click on the link I would send, and a form would open up, showing his name, populated by the first table, and showing two drop down menus, populated from the Long OT and Short OT tables. He would select one from each (or None, which would be a option) and Submit it.
The form action would be to place his name in the Assigned field for the OT he picked, and place a Yes in the Picked field.
When the next person in the list opens the form, it has moved down to number 2 on the Personnel list, Cheryl Peterson, and shows her the remaining OT selections (excluding those that have a Yes in the Picked column).
Any suggestions or comments or better ways to do this would be appreciated.
First, I don't think ms access would be able to (easily) kick off the process based on a hyperlink. You may be able to do something by passing a macro name to a cmd prompt but it would take some mastery to get it working properly. Could you instead create a login form to get the current user? If you do that you don't really need to display the personnel list, just keep track of who has not yet responded to the OT request. Essentially at that point all you would need on your form is a listing of the available OT and a button that creates the assignment. Also it may be easier (and a better design) to only have one table for the OT listings and add a column for the type of overtime (long/short).
What if Cheryl isn't the 2nd person to get the form? Your concept goes out the window.
Instead, I would keep a table of all user names, and their security level. managers can see everything, individual users can only see their record. This would be done by using a query behind the OT Picks form, and either filtering by the current user or not filtering at all. I have done many of these types of "user control" databases and they all have worked well.
As for the actual OT tracking, I agree with Steve's post in that it should be done in one table This would be the preferred method of a concept referred to as "normalizing data". You really want to store as little data as possible to keep the size of your database down. As an example, your Login table would have the following fields:
UserID
FirstName
LastName
SecurityLevel
Address1
Address2
City
State
Phone
Etc... (whatever relevant info pertains to that person)
Your OT table would look like this:
UserID
OTDate
OTHours
OTType
Etc... (whatever else is relevant to OT)
You would then join those 2 tables on the UserID fields in both tables any time you needed to write a query to report OT hours or whatever.
I am trying to work around a limitation that Filemaker 12 seems to have. In a value list that links to an ODBC attached SQL Server database, it doesn't display every piece of data. If there are 2 people with the same last name for example, it only displays the first person with that last name in the list. This is verified by the following in the Filemaker documentation (which I found after a lot of digging)
If the value list is defined to display information from two fields, items will not be duplicated for the field on which the value list is sorted. For example, if the value list displays information from the Company field and the Name field, and if the values are sorted by the Company field, only one person from each company will appear in the value list.
Portals on the other hand will find all the related data, I just don't understand how do something with the data once I get it in the portal. I essentially thus wish to use a portal AS my drop-down value list, and then to use it as I would have a value list (which is then to act as the key to do the rest of the lookups on the page to fill out the invoice.
The major issue here (other than this maddening choice Filemaker seems to make) is that the external file I am pulling the data from is an ODBC mounted SQL Server file, so I can't do something easy like a calculated field which would give me last name & " " & first which would make almost every person unique. Filemaker won't let me do that because it says I can't do that with a field that is not indexed. Any help would be greatly appreciated!
Assuming that we're starting with table MyTable and we're trying to get a ID from the People table for the selected person, which we'll call ID so that we can put it into MyTable::PersonID
Start by creating a new Table Occurrence of your People table and call it PeopleWhoCanBeSelected. If you want every person in the People table you can connect it to MyTable with the X relationship. If you want to show just a subset of the people you can build a different relationship.
Now, on a layout displaying records from MyTable you will make a portal showing records from the PeopleWhoCanBeSelected table.
In the portal put a button. When that button is pressed use the Set Field script step:
Set Field MyTable::PersonID to:
PeopleWhoCanBeSelected::ID
That should do it. You can make the button an invisible overlay on the entire portal record if you like, so that the user clicks on "the name" instead of "the button next to the name".
Now, if you want to pull additional data through to the MyTable record, you'll need to create a second Table Occurrence, called People with the relationship MyTable::PersonID = People::ID. Then you can get information on the specifically chosen person through that relationship.
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?
I'm trying to copy some field values to a duplicate database. One record at a time. This is used for history and so I can delete some records in the original database to keep it fast.
I don't want to manually save the values in a variable because there are hundreds of fields. So I want to go to the first field, save the field name and value and then go over to the other database and save the data. Then run a 'Go to Next Field' and loop through all the fields.
This works perfectly, but here is the problem: When a field is a calculation you cannot tab into it and therefore 'Go to Next Field' doesn't work. It skips it.
I though of doing a 'Go to Object' but then I need to name all the objects and I can't find a script to name objects.
Can anyone out there think of a solution?
Thanks!
This is one of those problems where I always found it easier to do an export/import.
Export all the data you want from the one database, and then import it into the other database. All you need to do is:
Manually specify which fields you want to copy
Map the data from the export to the right fields in the new database/table
You can even write a script to do these things for you.
There are several ways to achieve this.
To make a "history file", I have found there are several cases out there, so lets take a look.
CASE ONE
Single file I just want to "keep" a very large file with historical data, because I need to erease all data in my Main file.
In this case, you should create a "clone" table (in the same file ore in other file, is the same). Then change any calculation field to the type of the calculation result (number, text, date, an so on...). Remove any "auto entered value or calculation from any field, like auto number, auto creation date, etc..). You will have a "Plain Table" with no calculations or auto entered data.
Then add a field to control duplicate data. If you have lets say an invoice number (unique) for each record, you can do this to achieve this task. But if you do not have a unique field that identifies the record as unique, then you have to create one...
To create such a field, I recommed to add a new field on the clone table and set as an aunto entered calculation and make a field combination that is unique... somthing like this: invoiceNumber & "-" & lineNumber & "-" " & date.
On the clone table make shure that validation is set up for "always", and no empty values allowed and that this value is unique.
Once you setup the clone table... then you can import your records, making sure that the auto enty option is on. Yo can do it as many times as you like, new records will be added and no duplicates.
If you want, can make a Script to do the move to historical table all the current records before deleting them.
NOTE:
This technique works fine when the data you try to keep do not have changes over time. This means, once the record is created is has no changes.
CASE TWO
A historical table must be created but some fields are updated.
In the beginnig I thougth a historical data, never changes. In some cases I found this is not the case, like the case I want to track historical invoices but at the same time, keep track if they are paid or not...
In this case you may use the same technique above, but instead of importing data... you must update data based on the "unique" fields that identifiy the record.
Hope this technique helps
FileMaker's FieldNames() function, along with GetField() can give you a list of field names and then their values