Jump to content

Dan D Lyon

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Dan D Lyon

  • Rank
    novice
  1. Dan D Lyon

    Db design...

    Thank you gentlemen. I downloaded a trial version of fm10 and the script trigger (onRecordLoad) feature solves my issue nicely. Upgrading soon. I wish the new UI could toggle to the old style side menu ... now I have to redesign my layouts to fit the window so as not to have to scroll so much... oh well. Thanks again also for all the other ideas and info to study.
  2. Dan D Lyon

    Db design...

    Each case type has this Side Panel calculation field, but with a different equation to determine its required size. My apologies for not being more precise, I'll try again... All type cases have the same 4 input number fields (height, width, depth and cover thickness). The specific calculation fields for each case type cut sheet are are in a specific layout for each case type. When stepping through the records while in a 1/2 inch cover type case layout and the next record is intended as a 1/4 inch rack type case, this displays erroneous results. Each record must only be displayed in its corresponding layout with its intended part size calculation fields. Here are some pictures of a few flight cases... http://www.calcases.com/
  3. Dan D Lyon

    Db design...

    Thanks for these interesting ideas.... more to digest....... I'll be back...
  4. Dan D Lyon

    Db design...

    I should mention that tables are new to me. The prior version of Filemaker I had was 3, no tables then. An example of one of the many calculation fields that are subtly different for each case type: (text result) Side Panels = Width & " x *" & Let([ integer=Int(Evaluate ( Substitute ( Height ; " " ; "+" ) ) - .3125) ; numerator=Mod(Evaluate ( Substitute ( Height ; " " ; "+" ) ) - .3125 ;1)]; Case(integer;integer &" ";"")& Case(Int(numerator*64) < 1;""; Mod(Int(numerator*64);32) = 0; "1/2"; Mod(Int(numerator*64);16) = 0;Div(Int(numerator*64);16) & "/4"; Mod(Int(numerator*64);8) = 0; Div(Int(numerator*64);8) & "/8"; Mod(Int(numerator*64);4) = 0; Div(Int(numerator*64);4) & "/16"; Mod(Int(numerator*64);2) = 0; Div(Int(numerator*64);2) & "/32"; Int(numerator*64) & "/64")) Most of this calculation is for decimal and fraction conversions back and forth. Measurements can be entered as either decimal or fractional, but the results are always fractional; to be implemented in the woodworking world of tape measures. The formula above I cut and paste from searches in decimal/fractions conversions in this forum and then adapted them together. I did not write them nor fully understand them, but they work. The sole reason for isolating the records of each case type is that it is imperative that the figures for one type of case are never able to be overlaid on any other case type. So that what is called a "cut sheet," the print out with all the correct parts to be cut, when handed to the builder, is such that there is no possibility that they inadvertently build the wrong type of case. All case types have 3 dimensions and cover thickness, but they have different size and type parts and have specifically different attributes (for instance strength and weight). When using the format of option 2, where all the records for all case types are combined in one table, and there are different layouts for each case type cut sheet, making sure that when you flip through the records that the correct layout is selected for each record is the trick. It just seems prudent to keep them separate. The only link they have is by client, job number and materials expenses, but these are of secondary importance at this point of development.
  5. Dan D Lyon

    Db design...

    "A table is a collection of records - basically a shoebox with cards. A file is a collection of one or more tables. A solution is a collection of one or more files." This sounds like option 1. -- A file for each of 8 case types. "I still don't understand the main issue here: suppose you have a table of Cases, with fields for: • Height • Width • Depth • CoverHeight • CaseType (one of 8 possible types) What additional attributes (i.e. fields) are necessary to describe an individual case?" All the calculation fields that are unique to each case type that contain its precise parts measurements. These fields are presented in a unique layout for each case type. At the top of the Define Database window under Tables it says: "A table is a unique set of records and fields. A file can contain more than one table." This is exactly what I want. It would be very nice if I could duplicate a table with all my intricate field calculations that I could then edit instead of having to cut and paste each field and its calculation formula. I googled an application that says it can do this, called FMfobot, for $199, think I'll pass. Otherwise I can do this by option 1 -- by duplicating my original file 7 times.
  6. Dan D Lyon

    Db design...

    I appreciate your help, thanks for bearing with me. Hopefully I'll get my needs across more clearly and understand your recommendations better... The most important part of this database is to be able to enter the dimensions for a specific type of case, plus the cover height; for instance: 24" high x 30" wide x 16" deep and the cover 4" high. Then with many calculation fields create a cut sheet layout with the many size parts needed... and also calculate materials costs with labor for pricing each custom case. As I said, there are 8 different types of cases (and which I wasn't so clear) with variable sizes for each job. The software we are currently using virtually has a file for each type and each job has its own record within each file. To adapt to Filemaker it seems there are three options: 1. Create 8 separate files with duplicate fields, though edited for each type. 2. Lump all 8 types into 1 file and table with all the fields named separately and use find/sort/different layout reports to separate and work with any one case type and job at a time... or 3. Have one file with each case type being a table, with duplicate, but altered sets of fields and isolated sets of records for each type. Option 3 makes sense to me, unless I have the concept of tables all wrong. Many of the fields are similar for each case type, so once creating all the calculation fields for one type table, it would be nice to be able to duplicate that table and all of its fields and then edit each tables set of fields for each case types parameters and have all the case types records grouped separately. The problem with implementing this is that fm7 doesn't have a duplicate option for creating new tables. Am I wrong that the purpose of tables is to virtually group a number of files (called tables) into one database file. This is my understanding of what I've read about tables so far...
  7. Dan D Lyon

    Db design...

    Okay, I'm getting it. Use tables as sub categories, not as types, right?
  8. Dan D Lyon

    Db design...

    I neglected to say that each job would be a record, and the records would be grouped by case type. So are you saying under these circumstances, having each case type group, could be separate tables?
  9. Dan D Lyon

    Db design...

    This makes sense to me, I'm just learning the table concept and trying to adapt from HyperCard, which is quite different. The reason for this question was to try and emulate the HyperCard archival aspect of having a "card", like a snapshot, for each job. I'll go back to studying FileMaker and tables and not try to emulate HyperCard functionality. : Thanks much.
  10. Dan D Lyon

    Db design...

    I work for a company that makes road/flight cases. Almost 20 years ago I wrote some software using Macintosh HyperCard running on Mac OS 8.6. You enter the 3 dimensions in inches plus the cover height and it calculates a cut sheet, materials and labor pricing. Time is long past to remake this application run on our new computers (before our old macs become extinct out from under us), and FileMaker seems to be the platform to retool to. My question is how to adapt the Hypercard concept into a FileMaker world. In Hypercard there is a stack for each of 8 different case types we make. Would it make sense to have 8 tables in Filemaker for each case type layout, or lump them all in one table and use 8 different layouts and some fancy find/sorting to keep them in their respective categories. We would never need to see the data from one type of case in any other than its own type layout; that could potentially be a real problem. Also, we'd like to keep an electronic archival linked with our client db (move away from the old paper filing cabinets) and maintain our vendor contacts all in one place. Thanks for helping me see how to manage this addaptation.
×

Important Information

By using this site, you agree to our Terms of Use.