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.