Jump to content

BoomC

Members
  • Posts

    12
  • Joined

  • Last visited

BoomC's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Comment, Point taken and I will keep out of the fray until my bio says ... Skill: Advanced. Bad advice is worse than no advice.
  2. I'm afraid you're getting into the parts of FileMaker that are making me flail so I can't be much help anymore. I sure don't want to guess and steer you wrong! I did look at your sample db and can make a few recommendations. First off, in your case I don't see a need to separate out the invoice order number and create a special Link Table. The invoice order is already the table that joins the other related tables. Second, instead of splitting Adtype and Photosize into seperate tables how about just moving AdType from Photosize to OrderDetail (my sample db). That way, you can set the AdType for each item ordered just as you do the quantity (or whatever). Try that out in TestSO1_Suggested.fp7 and see if it does what you want. As for your other problem you said: "...So that when a selection is made for say Birthday then a field called PhotoSize in the portal would display a value list of relevant records from the PhotoSize layout." I think what you are talking about here is a thing called "conditional value lists" and requires more than just relationships to do the trick. Look on the Database Schema > Value List forum for help with that. The Pro's have given some excellent, detailed answers (and sample db's) for this already so spend some time prowling the forum before asking a question. Do a forum search for the terms conditional value list and you should get all the threads on the topic. Good luck!
  3. Ahhhhh..... I would say "How could I have missed that?" but it doesn't say "novice" on the skill level for nothin'. It's really an adjustment getting used to how FileMaker handles things. I keep losing track of where I've set parameters and then miss them in the problem solving stage. Your help and patience appreciated.
  4. GlenHest, I forgot to mention that I've never done order or invoicing databases before so the cost/total cost fields are just tacked on. You would need to figure out how to get them to work properly. Sorry.
  5. I'm not sure I can help but I'm going to give it a try anyway. First off, when I look at your tables I see information being duplicated (Photo Size, Ad Type etc.) across several tables. As you probably know, the wonderful thing about a relational database like FileMaker is that you can group like (and unique) information into seperate tables and then link those tables to each other through relationships. All the Customer info into a Customer Table, Pricelist info into PriceList Table etc. Think about this in your design. Second, and in answer to your question, the advantage to a unique, serialized, number field is that it's garanteed to be, well... unique. If you set it up right, the ID Number field will be automatically filled in and the person doing the data entry won't be able to change it. The other advantage is that there is less kb overhead storing a related customer number "1" than storing related customer "Bynerman and Stevens, Inc." I worked up an example database to give you the idea. It has 4 tables: Customer, AdPriceList, Orders and OrderDetail (I added Customers just to help show relationality - you may not need it). Orders is the main table and the form that ties all the tables together is the Orders layout. When you look at the Orders layout, notice that information from the Customer, AdPriceList and OrderDetail is all present on the form but most of this info isn't stored in the Orders table - it's stored in the other tables. Only the key identifiying numbers are actually stored in Orders and OrderDetail. Check out the Relationship Graph, and the Orders and OrderDetail tables (table view) and you'll see what I mean. I hope this helps. Let me know if you have questions about the attached example file. TestSO1_Suggested.fp7.zip
  6. Well, I guess that's my question - why would the occurrence make a difference? I had it in my mind that the only difference between multiple occurrences of a table in the graph was how you set the relationships. These two occurrences have (seemingly) identical relationships on the graph but behave very differently. I'm guessing now that at some level a second occurrence table is very different from the first join. If this is so, how is it different and how do I solve my original problem- allowing add/delete of Images from MAIN on one layout but not another? I have attached a file that shows the problem better than I can explain it. Again, thanks in advance for any enlightenment. [Problem summarized: I have two portals on my layout (for example's sake). Portal 1 has a container field that comes from related table "Images". Portal 2 has a container field that comes from related table "Images 2" - a second occurrence of Images table in the Relationship Graph. Portal 1 behaves correctly by showing ALL related images (records). Portal 2 displays only the first related image, repeated many times. Why???] Relationship_problems.fp7.zip
  7. I'm not sure if this is a relationship or layout question but since I'm having difficulty picking up self-join relationships (new to FileMaker from Access) I thought I'd start here. I have a MAIN table that has a one to many relationship with an Images table. I would like two relationships for these tables: one that forbids adding/deleting records in Image from MAIN and one that allows it (different permissions for different layouts). Problem: When I create a second occurrence of Images (edit to and from DISABLED) and use that relationship to join the portal, my scrolling portal now shows only the first image (record) of the related records. Both table occurrences are based on the original Images table and are apparently identical in every way except for edit permissions enabled/disabled. When I base the portal on the the original occurrence relationship it works perfectly no matter what edit features are enabled. It's obvious that I don't really understand what's going on with second occurrences and self-join relationships. Could someone point me in the right direction on this? I would also welcome any recommendations for good literature on Filemaker relationships (I have "Using FileMaker 7"). I have the Table to Table concept down just not the other stuff. Thanks in advance for any help.
  8. Ahhh... I think I've got it now. Actually, I had planned to have a second, seperate "image manager" layout with the rows of portals you describe to make view all related, adding and deleting images more friendly. You've been a big help - thanks again!
  9. Hi, I'm trying to do the image trick you are and am having all the same problems. Check out the post "Mutiple images in one container" topic #173100. Fenton has given some great tips and a demo file. It might help you as well. Fenton has a second table with that contain the images which are cross-refeneced (and related) to your main table. You then bring the images that are related to the main record viewed through a portal (as JD reecommended). It's still tricky but it might do what you want.
  10. Fenton, This definately solves the problem but I'm going to have to play with it a bit to really understand what you've done. Thanks for the help and especially the example file. Getting to see the script and tables really makes things clearer. BoomC
  11. I am new to Filemaker (from Access) and have run into a problem I just can't get a handle on. I'm hoping one of you fine folks can point me in he right direction. Extra details are at the bottom of the post. In my main table (Catalog), each record can have many images associated to it. The number of images can vary by record from 0 to, say, 10. I would like to have one image display on the Catalog layout and be able to advance through the images one at a time using previous/next buttons. I have created a layout with a portal to the images and "next/previous portal row buttons. Problem is, when I test this, the next/previous buttons only work if I have all the portal rows showing on the layout. I have tried setting the portal up with a slider but the effect was poor (jumply etc.) I'd prefer not to go this route if possible - I want the images to jump so that only complete images show at any given moment. Sounds petty but there it is. Additionally, in my previous/next button tests, when all portal rows are showing and I select "next portal record" a gray "field select" haze covers the next picture. Is there a way to script it so the next row is displayed but the field isn't actually entered? Any help would be greatly appreciated. BoomC Details - if you want them: Related Image Table: Has three fields: a serialized primary key field, an ID field that holds the foreign key from the related Cataloging record and a container field for the image. Catalog Layout: Has a portal to the image table and two associated buttons using "Go to Portal Row [select; Next/Last]. Portal size is larger than the container it holds.
×
×
  • Create New...

Important Information

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