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.
Related
TblEmployees has Fname, Lname and EmployeeName fields. EmployeeName should be Fname + Lname (i.e. John Doe). I want to enter Fname and Lname in a form FrmEmployeeData, and update TblEmployees with Fname, Lname and EmployeeName.
If FrmEmployeeData has as Data Source TblEmployees, how do I get the concatenated [Fname]&" "&[Lname] into the EmployeeName field of the table?
I also tried changing the DataSource of FrmEmployeeData to a query QryConcatenateFname&Lname where EmployeeName:[Fname]&" "&[Lname]. This gave the correct "John Doe" in the query result but I could not get it to update the TblEmployees.
What am I doing wrong? Thx.
It looks like you are learning access as this question is really too simple for stack overflow. Instead consult an Access book at your library or start finding Youtube vidoes and tutorials on the internet. Having said that here is a start:
Access gives you the ability to add a calculated field to a table in the design tab by treating it as a DataType. You can also add lookups and some data validation. Never do any of that!! Use forms to enter and search the data, and use reports to print the data.
A simple yet quite incomplete explanation is that as your database expands into multiple related tables you will find that entering the data directly into the tables is error prone for the database designer yet alone the clients. Because any observation will be distributed across multiple tables it becomes easier and easier to forget one or make a mistake as you add more and more tables.
Access is designed for quickly making simple forms for the tables in your database. If your relationships are already entered using the Relationships tool Access even generates starter forms that handle 1 to many relationships. Just click on a table and under home then forms group on the ribbon choose either form or form wizard and start playing with your new forms properties:
if you don't see the properties (hit f4 in most cases). Seriously every control has properties you can play with. In particular look at the control sources and for the form itself (hit the top left corner to select the form) check out the default view property.
I happened to include EmployeeName as a string in tblEmployees but there was no need other than having access put the EmployeeName textbox on the form. I would have to go back and delete EmployeeName from the table which is about the same effort as adding the textbox to the form myself. Below I show how to set the control source for EmployeeName to the usual FullName calculation
=[Fname] & " " & [Lname]
Access forms by default have both data entry and search capabilities. Play with the record selector highlighted at the bottom of the beautified form below. You can edit any record you see and the changes will appear in the table. If you go past the last record you can add a new record.
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 relatively new to Filemaker programming, but I have come across what I thought was a bug, which I have been tearing my hair out trying to squash, only to find it is more a "feature" than a bug. I have a field set as the key for lookups in a ms sql database which I have created a relationship with. I have it set as a drop down, and it is showing 2 fields (last name and first name). Unfortunately, it only shows 1 person per last name in the sorted list (example, there are 5 people with the last name "Bennett" but only 1 shows). After driving myself nuts trying to find the error, I found the following in the filemaker troubleshooting section:
"
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."
As I read it, I can't do what I need to do with a value list (display EVERY last name from the sql file) so what other options do I have? I have experimented with creating a portal which DOES show a list of ALL the last names and first names, but I don't know/understand enough to know what logic/functionality I need so if I click one of the people in the portal list it will do the same thing as if I clicked it in a dropdown value list, which is to then do the lookups and populate the rest of the fields in this database from the information in the record in the sql database. Any and all help would be greatly appreciated, and I appreciate any help any of you can offer. Thank you!
There might be some things that cause this;
You cannot create a link based on a calculation that needs to be calculated each time (Filemaker does not know what to do with this, logical in a way)
Based on what you do I would personally link the two tables based on an lets say company ID instead of a name, as a one to many join. This will definitely eliminate the 'feature' filemaker has of showing unique names only in the joined table. On database level I would join on ID, on Value list I would select the ID as first field and the (calculated) name as second field, than showing only the second field (option in the value list definition popup) for your selection list.
Hope this helps.
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 table like this:
Application,Program,UsedObject
It can have data like this:
A,P1,ZZ
A,P1,BB
A,P2,CC
B,F1,KK
I'd like to create a layout to show:
Application,# of Programs
A,2
B,1
The point is to count the distinct programs.
For the life of me I can't make this work in FileMaker. I've created a summary field to count programs resetting after each group, but because it doesn't eliminate the duplicate programs I get:
A,3
B,1
Any help much appreciated.
Create a a summary field as:
cntApplicaiton = Count of Application
Do this by going into define fields, create a field called cntApplication, type summary. In the options dialogue make the summary field a count on application
Now create a new layout with a subsummary part and nobody. The subsummary should be sorted on Application. Put the Application and cntApplication fields in subsummary. If you enter browse mode and sort by Application you ought to get the data you want.
You can also create a calc field with the formula
GetSummary(cntApplication; Application)
This will allow you to use the total number of Applications with in a record
Since I also generate the data in this form, the solution I've adopted is to fill two tables in FileMaker. One provides the summary view, the other the detailed view.
I think that your problem is down to dupliate records and an inadequate key.
Create a text field called "App_Prog". In the options box set it to an auto-enter calc, unchecking the 'Do not replace...' option, and use the following calc:
Application & "_" & Program
Now create a self join to the table using App_Prog as the field on both sides, and call this 'MatchingApps'.
Now, create (if you don't alread have one) a unique serial number field, 'Counter' say, and make sure that you enter a value in each record. (Find all, click in the field, and use serial number option in'Replace Field Contents...')
Now add a new calc field - Is_Duplicate with the following calc...
If (Counter = MatchingApps::Counter; "Master Record" ; "Duplicate")
Finally, find all, click in the 'Application field, and use 'Replace Field Contents...' with a calculation to force the auto-enter calc for 'App_Prog' to come up with a value.
Where does this get you? You should now have a set of records that are marker either "Master Record" or "Duplicate". Do a find on "Master Record", and then you can perform your summary (by Application) to do a count of distinct application-program pairs.
If you have access to custom functions (you need FileMaker Pro Advanced), I'd do it like this:
Add the RemoveDuplicates function as found here (this is a recursive function that takes a list of strings and returns a list of unique values).
In the relationships graph, add another occurrence of your table and add an Application = Application relationship.
Create a calculated field in the table with the calculation looking something like this:
ValueCount(RemoveDuplicates(List(TABLE2::Program)))
You'll find that each record will contain the number of distinct programs for the given application. Showing a summary for each application should be relatively trivial from here.
I think the best way to do this is to create a separate applications table. So as you've given the data, it would have two records, one for A and one for B.
So, with the addition of an Applications table and your existing table, which I'll call Objects, create a relationship from Applications to Objects (with a table occurrence called ObjectsParent) based on the ApplicationName as the match field. Create a self join relationship between Objects and itself with both Application and Program as the match fields. I'll call one of the "table occurrences" ObjectsParent and the other ObjectsChildren. Make sure that there's a primary key field in Objects that is set to auto-enter a serial number or some other method to ensure uniqueness. I'll call this ID.
So your relationship graph has three table occurrences:
Applications::Applicaiton = ObjectsParent::Application
ObjectsParent::Application = ObjectsChildren::Application, ObjectsParent::Program = ObjectsChildren::Program
Now create a calculation field in Objects, and calculating from the context of ObjectsParent, give it the following formula:
AppCount = Count( ObjectsChildren::ID )
Create a calculation field in Applications and calculating from the context of the table occurrence you used to relate it to ObjectsParent with the following formula:
AppCount = ObjectsParent::AppCount
The count field in Objects will have the same value for every object with the same application, so it doesn't matter which one you get this data from.
If you now view the data in Applications in list view, you can place the Applications::Application and Applications::AppCount fields on the layout and you should get what you've requested.