Jump to content

elo

Members
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

0 Neutral

About elo

  • Rank
    member
  1. Ok, I'm gonna stop at this point b/c with the corrupt files I just cannot be sure that I understand your DB. I'm not sure if each "CalcSheet" can have multiple trips or not, I decided NOT in the way I laid things out, but maybe they can. That said, if you use a more FM7 like structure it will be easier for other to help you AND you should be able to show SUMMARY fields on a suitable layout that subtotal the fields you want across relationships. Sample.fp7.zip
  2. Ok, I've redone this FM7 style with a single file and attach the relationship diagram. CalcSheet in the original solution does NOT record Truck ID's this is a bug IMHO. A better name for Calcsheet would be mCustomersTrips (using my nomenclature) so I've moved the truck ID over to the Trip record since it didn't really make sense on the calcsheet, though it could be there. For trips, I've eliminated the overly complex 2 types of lineitems (mileage, fuel) and replaced with one. Then I'll try to send the calculations and files that avoid 50 relationships (1 per state) to calc
  3. Just saw this today (8/22), anyhow, some of the files are corrupt (Line Items.fp7 among them). I cannot make sense of this entirely, but am trying to create something simplified in FM Pro 9 to send back to you.
  4. You don't make what tables you have clear, but I'll see if I can help. You need at least three tables. 1) Recipes table 2) Ingredients table AND 3) RecipesIngredients table to support a many-to-many join. Recipes will have the fields: recipe_id, RecipeName Ingredients will have the fields: ingredient_id, IngredientName RecipesIngrdients will have the fields: recipeingredient_id (optional field, but recommended), recipe_id, ingredient_id The tables will need to be connected up by relationships in the data diagram with the proper _id fields conne
  5. Assuming I understand this correctly, you have a table like Students and another table StudentModulesTaken. When a student is created, you want to create 18 StudentModulesTaken records? I cannot think of anything short of a button that invokes "Perform Script" on a custom script to do this. The basic flow of the script would be to get the "primary key" or ID field for the StudentTable, then go to a layout for the StudentModulesTaken table, and start creating 18 records with the necessary items. There may be some fancy shortcuts, but at the end of the day, that's what you are goi
  6. Micah still not sure what you are asking. Just to give a non-ESS example, if you have a table tBigTable that is part of lots of table occurrences (TOs) in the data diagram, even if you just create tNewSmallerTable right in FMPro there isn't going to be a tremendously easy way to "swap" everything pointing to tBigTable to tNewSmallerTable easily and "giving it the same name" doesn't help. So, any way you dice it, you are going to have some FM work to clean things up when you start normalizing your data.
  7. I'm not 100% sure I understand your database, but the simpler way to track this which would also make "rollups" easier is more many-to-many relationships using an intermediate table. Here's what I would do for tables and part of the relationship diagram: tCustomers -> tTrucks -> tTrips -> tMileageItem -> tFuelItem Somewhere you need a lookup table, lStates, each tMileageItem and each tFuelItem would have a stateID from lStates. You should then be able to use summary fields with breaks at changes in stateID for rolling up the sum
  8. Can you post what script step options you are using? If you did a Set Variable[$outputfile; < Then your save as PDF should be able to accept $outputfile the destination.
  9. Not 100% sure what you are trying to achieve, but I suspect there is not going to be an easy automagic way to swap the table occurrence (TOs) of all relationships from CurrentFMTable to ESSMYSQLTableNamedCurrentFMTable...
  10. You'll probably get more help if you post the relationships in your db, but long story short. In FMPro, you are going to need to create enough table occurrences to "walk" from (connect) SALESLINES to PRODUCTS. Then all you need to do is generate a layout of quantities for each product during a sales period. As for reconciling the inventory, you probably need some more tables to store the weekly inventory results and then compare the two values.
  11. So, it isn't 100% clear what you are doing, but I am guessing you do not have a key field. The "right" way to set this up is for Accounts to have an "id" field which is unique/auto-enter serial number. File needs to have an "account_id" field. You need to change that account_id field. My guess is that you are instead changing the accounts::firstname field. Erik
  12. Ok, the first issue I was seeing was a transcription error by me. Many thanks to LaRetta for suggesting contacting Nightwing/Ray directly. The others are possible enhancements/corner cases that you may hit/desire if implementing the technique. Again, great book and awesome author for responding.
  13. I've seen this behavior too, I just ended up adding a script step to maximize my original window after closing the utility window.
  14. So, been enjoying the "FileMaker Pro 9 Bible" and decided to implement the saving of the find requests for one of my central layouts. In the process I identified a few glitches in the basic code provided. The first issue was that if your special save--and-do-find script was triggered when no field was active, the script would loop endlessly. The second issue was that the ActiveFieldTableName was not saved this means that if you had two fields (in different TOs) on a find layout then only the first by tab order is "accessible" to the saved/played back find. A third issue was
×
×
  • Create New...

Important Information

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