javabandit

It actually doesn't open a new browser window in that instance. When I use 64-bit FM to display the DWF, it opens the native DWF viewer application (Autodesk Design Review).

I think so. I opened my test solution above and put this address in the address bar: https://www.whatismybrowser.org/ If I do it in the 64 bit version of Filemaker, I see this: 64-bit Edition If i do it in the 32 bit version of Filemaker, I see this: 32-bit compatibility layer This is all on the same Win7 computer.

It's 32 bit. As far as I can tell, there is no 64 bit version available. So, the question is: Is it possible for the 64 bit version of Filemaker to use 32 bit applications inside the Web Viewer?

Hey Everyone, We have discovered the problem! Unfortunately, we still don't have the answer. The problem seems to be with 32 bit vs. 64 bit versions of Filemaker 14. I installed the 32 bit version on my system, and then my DWF viewer did open inside the web viewer, just like it has with FM13. But, installing the 32 bit version in our whole company is really not an option, especially since we have moved to the 64 bit version of MS Office, and we need 64 bit Filemaker to work nicely with that. So, now here is my question: Is there a workaround so that I can continue to use the 64 bit Filemaker 14, and enable it to display the 32 bit DWF viewer in the Web Viewer layout element? This will be on Win7, and Windows Server 2012. Thanks in Advance

I'm just writing to clarify this problem. I still haven't found the solution. With Autodesk Design Review installed on the system, I can open the DWF files directly with Internet Explorer. It will display the file right in the browser. And, when I use a web viewer in Filemaker 13, it shows the DWF in the web viewer. But, when I do the same with Filemaker 14, it does not open in the web viewer. Instead, I get a dialog box to open it in an external application. Thanks in advance for any insight you may have to offer.

Hi Everyone! I have a problem with something that works fine in FM13, but does not work in FM14. I am using a web viewer to display a *.dwf file, which is an Autodesk file we use commonly for displaying drawings. For those who are unfamiliar, think of it as Autodesk's version of a *.pdf. I'm running Windows 7, and I have the Autodesk Design Review Software installed. When I access the file in Filemaker through the web viewer in FM 13, it displays right in the web viewer, which is what we want. If I do the same thing in FM14, however, it wants to open in the outside application. To demonstrate this, I created a stripped down version for FM13, and one for FM14, and I've included a TEST.DWF file. To use my tests, you would need to save the TEST.DWF file, and insert it as a file reference using the "Insert File Ref" button. Then, you should be able to toggle between "Show Google.com" and "Show File Ref" to demonstrate the problem. Any help or insight would be greatly appreciated. TEST.DWF FM 13 Web Viewer.fmp12 FM 14 Web Viewer.fmp12

Hey Everyone, I've been arranging and polishing this file, and I am finally ready to present it to the group here that will be using it. So, I figured I'd post the file in case anyone is curious how it looks now that I have everything in place. Thank you so much for all the help. (especially comment) Of course, I would love to hear if anyone has any further suggestions for improvement. Thanks again - Tool_List.zip

Brilliant LaRetta! I made both those changes as suggested. I use that Go To Layout, then Enter Find Mode all the time. I'm thinking I should go back through some of my other Filemake files and reverse that. I could probably get some pretty nice performance gains, especially on those that have a lot of records. Thanks for the tips!

Oops indeed. I went back and attached the file on the previous post. It's there now.

Okay. I've got it working. There are two files in the attached zip file. forum_help1.fmp12 This is a new database file, where I attempted to create the tables, fields, and relationships that you suggested. I think it's successful. The layout I created works, and is super basic. forum_help2.fmp12 This is a copy of the first one, where I added some things that will be closer to how I will want the user to interact with the database. I realized that the gToolType field, although working as you suggested, was probably a little too narrow, and not necessary for selecting tools that need to be joined. So, I eliminated that. In general, a single part number will not have more than 7 or 8 different tools, so we don't need to narrow by type. It's probably going to take some time for this to sink in so I can understand the relationships. It's fairly easy for me to think of something like Students--<Join>--Classes. But, if you replace Students with PartNumbers, and Classes with Tools... I must have a special case on my hand since the Tools are only known by the PartNumbers they produce. They don't have an identity of their own like a Class does. It's a little strange. I'm really happy with how this is working, and I really appreciate the help you have offered. I'm going to keep these two files as examples and work this logic into my solution. It will be neat for me to see how it all works when I have all the other data fields available, and see how the users will be able to manage the data. Thank you again. <Edit: Attached the file that I forgot to attach before> forum_help.zip

Your first paragraph describes what I already have.... a partnums table, a tools table, and a join table using the primary keys. That's where I started on this. And, that's were I was also beginning to doubt myself. So, I appreciate you confirming that I was on the right track with a many-to-many relationship. To answer about the source of the data: It comes from the Engineering dept. Whenever we start a new project for a customer, the Eng. Dept. assigns the part numbers, and determines what kind of tooling is necessary to make new parts, and also if similar parts can be made in the same tooling or whatever. So, they put that info into a packet that includes all kinds of other info about how to process the parts, production rates, drawings, quality info, etc. As for the UI recommendations, I think I understand what you are proposing. It makes sense to me, I just need to try it out to really know if I understand or not. Thank you, comment. I will give it a try today and post back my results later.

I'm sorry, I guess I did muddy it up too much. I'll try again. When it is time to add records to the database, the user will have a packet of information for the project. The packet will show the new part numbers that we will be producing, and what tools are needed to produce those numbers. So, the database user will already know ahead of time what part numbers and what tools go together. So, going back to my original post, they will have this kind of info at their fingertips: Part #123 requires a Mold, a Trim Die, and a Secondary Part #124 uses the same Mold, and same Trim Die, but no Secondary Part #125 uses the same Mold, but a different Secondary Ideally - The user will first add a record to the partnums table for Part# 123. Then, they will add three new records to the tools table, one for the Mold, one for the Trim Die, and one for the Secondary tool. These records are joined to Part#123. Next, they enter Part# 124 in the partnums table. They will need a way to select the existing Mold and Trim Die records from Part#123, and join those two records to Part#124. Finally, they enter Part# 125 in the partnums table. They then need a way to select the existing Mold from Part #123 and Part #124, and join it to #125. Also, they need to add a new record for the "different" Secondary tool and join it only to #125.

I seriously appreciate this discussion. Thank you. 1. The significance of splitting is due to the concept of "series" and "number within the series". Together they make the part number. So, for example, a customer of ours has an "Alpha" project. We will pick the next available number to start a new series. In real life, our next number will be 5581. Then, each part for the Alpha project will be numbered 101, 102, 103, etc. The part number becomes 5581101, 5581102, 5581103. If the start a "Beta" project, we will start with the next series - 5582. Similarly, when we get a new customer who has their own new project - we start a new series, say 5583. The major caveat is this: Not all part numbers are done that way. We have lots of legacy numbers with no "series" - just numbers and letters. That said, with my new solution, I am trying to avoid the "series" and "number within the series" model. I am trying instead to just have partnumber be a field of its own. 2. The UI - Putting structure aside: I think the best way for a user to make joins is to allow them to enter partnumbers in the partnum table, then either add a brand new tool to the tool table (because the tool doesn't exist in the table yet), or select an existing tool from a portal list. I tried to do this already by creating a calculated field in the tools table that was just a List of the partnumbers. It's like this: c_partnums_for_this_tool = Unstored, = List ( partnums::partnum ) I can present this to the user in my tools portal for them to select from. So, as far as that goes, it's okay. But, the problem is that I will have so many records in that list that they will be scrolling through 20,000 or so records to find the one they need. I also tried filtering by tool_type, so they shorten the list a little, but it's still going to be between 2,000 and 9,000 records or so to scroll through depending on the tool_type. Finally, I attempted to create a relationship to let the user "narrow in" on the list by typing the part number in a filter field, then making a relationship like this: c_filter >= c_partnums_for_this_tool AND c_filter <= c_partnums_for_this_tool where c_filter = List ( g_filter ; g_filter & "ΩΩΩΩ" ) It's a technique I use a lot to narrow down a long list of part numbers in a portal. It doesn't work here, though, because c_partnums_for_this_tool is an unindexed, calculated value. So, the relationship doesn't work. Okay, I think I went overboard in explaining things. I hope I didn't muddy it up too much.

Yes, exactly.  That "map" looks something like the attached picture. I'm only showing three lines for simplicity. So, the second line means this: The tool will make these part#'s 5116102 & 5116103. It is located on Rack H, Row 1, Carton 7 (H 1 7). The third line is similar - it makes part# 5113102 and 5113103. The first line is for a tool that makes many part numbers. In this case, these are all from the molds department, so these are only molds. There are similar "spreadsheets" for other types of tools (Trim Dies, Secondaries).  Thank you again for your consideration.  Edited my profile: Using FM Pro Advanced 13.0 - Win7

Thanks comment, your question hits at the core of my problem. You're right that the mold to make #123 is the same as the one used to make #124. In this case, we call it a "two-cavity mold." When we use that mold, we will produce two different parts: One from each cavity. This is common with left-handed and right-handed parts. Let's say it makes one left-hand bracket (#123), and one right-hand bracket (#124). Customer A only buys left handed brackets, and Customer B buys both. So, we will issue shop orders to produce whichever part# we need to fill our inventory. So, if the shop order is for part #124, the person setting up the machine will go get "the mold for part# 124" which also happens to produce part# 123. That's why we call it differently in different contexts. How many molds do we have in total? Roughly 20,000. How do we tell them apart in practice? There are locations assigned to them that are basically spots on a shelf, or a bin. We have lots of shelves and bins containing the different tools, and each department has a printout of the whole list that shows the various part numbers, and where they are located. So, in the example, the person reading the shop order would look at that printout, find the location, and pull out the tool they need to make the part number. That list is little more than a spreadsheet where things are roughly organized. My project is to make this into a relational database where it's easy to see which tools you need to make a part# and which part#'s the tools can make, and where those tools are located. Also... currently, there are three "spreadsheets" - one for Molds, one for Trim Dies, one for Secondaries. I intend to make it into one "tools" table. I hope this is more clear. Thank you for your consideration.

Hi Everyone!  I have a situation where I think I need a many-to-many relationship, but I'm struggling so much with how to make the user interface for the joins, that I'm beginning to doubt that many-to-many is really the answer in my case. Here's the scenario:  We have tools that make more than one part number. We have part numbers that need more than one tool to make.  So, I set up three tables: partnums ---< join >--- tools  partnums::kp_partnum = join::kf_partnum tools:kp_tool = join::kf_tool  So far, so good. My problem is when I want to create an interface for a person to make the join relationships. We will have a list of approximately 25,000 partnums, and maybe that many tools too. But, we don't have a unique way to refer to the tools. That's where my problem comes in. We refer to them by the part numbers that they create. Here's an example:  Part #123 requires a Mold, a Trim Die, and a Secondary Part #124 uses the same Mold, and same Trim Die, but no Secondary  If we had to make Part #123, we would say, "Go get the Mold, Trim Die, and Secondary tool for part#123." Or, if we had to make Part #124: "Go get the Mold and Trim Die for Part# 124." In this sense, my situation is different from a " students --< join >-- classes " type of situation because my tools are identified by the part number they create, and don't have recognizable "names" like classes do.  So, I can easily make a layout to display all the partnums in a portal, and all the tools in a portal, and a join table showing which belong together. But, if I wanted to add a new partnum - say #125 - and it uses the same Mold, and Secondary from #123 & #124.... how do I identify them to pick those two tools from the tool portal?  I've attached a screenshot to try and help visualize this.  Maybe I shouldn't be looking at a many-to-many.... but I don't know what else I should do. Any suggestions are very welcome. Â

Hmm.. So, since it's now hosted, I don't have an option to "keep" new settings do I?

Hi all, This has got to be a simple issue. I'm creating some new layouts for an existing database. It's hosted on FM server. Each time I open the database, and go to my "TEMP" layouts that I'm working on, I end up going to the View menu to un-check Page Margins, then View | Show | and un-check Buttons and Field Boundaries. Finally, in the Inspector, under position, I click the inch indicator twice to change it to px. Then, with all that done, I feel like I'm ready to work. But, if I close the database, and re-open it, I have to do all of that all over again. How can I make it keep those options? Thanks in advance.

Thanks Bruce. Yeah, this is not really the look of the final interface. I'll probably use a red X or "del", as I've used in other, similar, databases. The > was left over from when I was experimenting with a 2 portal setup where a user would "move" the records between the joined and UN-joined portals. What I'm most interested in is any comments related to my weird hidden-field, button script, and script trigger. Is this type of thing normal for adding records in a many-to-many, or am I just off the deep end? It seems to me like a bit of a kludge. Is there a more clean way to do it? Thanks for your time.

Hi everyone. One of the solutions I'm working on requires a many-to-many relationship. This is my first attempt at setting this up. We have tools and part numbers. The basic relationship can be phrased as such: Each tool may produce many part numbers. Each part number may require many tools to be produced. I've been working for several days learning the principles of a many-to-many join, and I now have a structure that works. The next big challenge for me is to make an interface that is easy to use. I've attached a clone file of the work I've done so far. As far as I can tell, this is working just fine. The reason I'm posting is that I feel as though I had to some sneaky trickery in order to get it to work, and I'm pretty sure there's a better way. (There's always a better way, eh?) Anyway, I would very much appreciate if some of you curious developers would take a look at my method and let me know what you think. Some info that would be helpful to know: - We have thousands of tools. Here I'm just showing a handful. - We have tens-of-thousands of part numbers. - Adding tools and part numbers is a frequent occurrance. A a major function of this database is to add new tools with their associated part numbers. Typically a user will think "I need to add this type of tool... and these are the part numbers that go with it." So, if you would be so kind, please open my file, select a tool (or add a new tool) and add a part number to it with the portal. My trickery comes into play because I don't want the user to decide if they are "joining" an existing part number to the tool, or if they are "adding" a new part number to the part numbers table, that would then be joined. This is not a 'polished' interface, I'm just working through the logistics of adding join records. I look forward to any suggestions you may have to offer. Thank you for your time. P.S. I -very- much appreciate the folks on this site, and I continue to recommend it to others. many_to_many_Clone.zip

Thanks comment. I haven't needed to do a merged letter before, but I'm sure I'll learn some things by looking through these files. I like your idea of the record load script trigger. It would be fairly simple to just keep a "formID" type of field and use that to trigger which layout to load. You're right, I don't really have a lot of layouts (forms) here. Most of these documents will remain the same for years before a revision needs to be made. So, it would be rather easy to keep the old layouts around. Thanks for the ideas.

Is there an example of the merged letters that I could look at? I can see how it would be easy to set up an auto-enter field to keep track of which revision of the form (which layout) was used. But, what I don't know is how to set things up so that you could do a find and get a meaningful display. For instance, suppose I performed a find for all the approvals by company XYZ in the last two years. I'd have a found set, but how do I move through the records so that I'm seeing the correct layout for each one? Wait, wait, wait... I may have just thought of it. If I hide the status toolbar and include forward/backward controls on my layouts, then I could script a "Go To Layout" for each click of the forward/backward buttons. If I do it well, the user wouldn't even know that they were changing layouts... it would just look like they were viewing different version of the "form" based on the date the record was created. Sorry for my rambling... I would appreciate any examples to look at, though.

Hi All, This is more of a theory question than a "help me with my problem" question. We have a number of small databases that we use to generate forms of various types. In most cases these forms are controlled documents. So, for instance, we have an official "Product Approval" form in Filemaker. In that form, a user can fill out the customer name, part number, date, etc... to request the customer's approval of a product. It has certain wording on it in sentences and paragraphs. The form is also given a designation: Form105. We also keep revisions of those forms. So, in my example the form is Form105 Rev A. Now, I want to make a revision to the form. That's easy enough. I can change some wording on the layout, I can add or move fields around. Then, I can increment the form to Revision B. But, what do I do about all the former records?!? Suppose that there were 2,000 records made when it looked like Revision A. Now that I've changed it to Revision B... those records aren't really quite accurate, since the wording on the form has now changed. Hopefully this makes sense. What recommendations do you have to manage this situation? Is there a "best practice" I should be following? Thanks in advance.

Not exactly... One problem that we have is people who forget to "punch out" when they are done with something. So, I do need it to continue to show the true interval (end - start as timestamps) so that it's easy for the shop manager to identify ridiculous entries and correct them. With all the suggestions above, however, I do have things working and displaying the way I would like them now. Thanks to all.

Okay Bruce... I've got it now. I added a bunch of copies of the same field to my layout and tested the different options for formatting the time. Now I see how it works. I was expecting the Inspector to act differently than it does. When I clicked on my time fields, I was thinking that the Inspector would switch over to the clock icon and display the settings I had last chosen. But now I see that the Number format applies at the same time as the time format, so it makes sense. Thanks for the help everyone!