Jump to content

Joel C R

Members
  • Posts

    12
  • Joined

  • Last visited

Joel C R's Achievements

Apprentice

Apprentice (3/14)

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

Recent Badges

0

Reputation

  1. I understand how to set a value list; that's not the problem. The problem exists in making one that can have values added (by other) and kept in the menu, without having to have other fields affiliated with the table. i.e. two tables SOURCE OUTPUT both have, for sake of simplicity, one field VALUES .. the field is the match field between the two tables. The idea is for someone working from the OUTPUT table to be able to add records to the SOURCE table via pop up menu using a value list defined by VALUES (from SOURCE). This works, if you have another field from SOURCE in the OUTPUT layout, ie SOURCE has two fields, VALUE and DESCRIPTION OUTPUT has one field, VALUE OUTPUT's layout is VALUE (pop up menu using value list defined by SOURCE::VALUE) SOURCE::DESCRIPTION If you enter a value for the second field, a new record will be created. However, if no value is entered, no new record. I was wondering if there's a way for a user to force FM7 to accept the new value defined by "other" in the popup menu without having to add a secondary field.
  2. I've been fiddling around with a database for a while, and I've figured that if you make a value list using match fields in related tables you can create new records in the "daughter" table via pop up menu. But I've also discovered that this can only be done if you have fields in the "daughter" table in the layout of the parent table. But what if you wish to create a value list that only affects one field (the one in the list) and allows permanent addition of new values? Joel
  3. I'm trying to build a database where the user only has to access one table. Any modifications to other tables could be done through this "master" table via relationships, value lists (pop up menus) and the like. The reason for this is simple: I'm building a database for use by other members of my lab, and its purpose is to create requisitions (for use through our organization's purchasing scheme). I've mentioned this in another thread, at a stage where the database was being thought of in an entirely wrongheaded fashion, and was much further from conception than it is now. I also failed to elucidate what the database entailed. So, I figured I would give it another shot and describe my current problem as carefully as I can: My database has (potentially) the following tables. REQUISTIONS (the "master" table, which pulls on data from all others. The reports are meant to be printed and submitted) REQUISITIONERS (data about the people making purchases) ACCOUNTS (data about the account numbers being used) VENDORS (data about the vendors, although not really necessary) PRODUCTS (data about the products) LINE ITEMS (link between products and requisitions) Right now, I'm using what I term a "relational value list" between the REQUISITIONS table and the REQUISITIONERS on the category of "name". I suppose I should employ a serial numbering format, but for aesthetics, I've stuck with the name. This is a small lab, and names are essentially unique here. So, I have NAMES as the match field between both tables and a value list defined by the NAMES field in the REQUISITIONERS table. Then, I use fields from the REQUISITIONERS table in the records of the master table. That way, you can use a pop up menu to either call up information about requisitioners or insert new records when needed. I don't know if this is considered a 'no no' or not, but it works quite nicely for my purposes. And thats the limit of my database's functionality (at least with regards to how I wish it to work). ACCOUNTS is supposed to be a two field table, with PRINCIPAL INVESTIGATOR (i.e. Boss) as the primary key/match field and ACCOUNT NUMBER under it. I'm trying to define a value list based on account numbers. This would also be called up by a field in the master table. The PRINCIPAL INVESTIGATOR is a field in the REQUSITIONERS table, and I've linked it to the master table via a lookup (not displayed in the record, so that you can enter data in the parent table via field insert). My problem here is that I cannot spawn new records in the ACCOUNT NUMBERS table this way. Now it gets more complicated. VENDORS, as it stands, is just a place holder for the VENDORS field. The contact information is irrelevant for these purposes, and I've considered defining a custom value list instead. However, the VENDOR field is crucial, because, due to the format that the organization uses for purchases, you are limited to one vendor per requisition. Therefore, the LINE ITEMS are regulated by the VENDOR. But the real problem begins when I try to use a portal (as suggested) to call up fields from the LINE ITEMS table (catalog number, description, price, quantity, total) of which the first three (catalog number, description, price) are simply lookups/references to the relatively static PRODUCTS table. The reason why this is a problem is because I'm trying to, as mentioned before, have everything done from the master table. So when you begin the database, it is empty, but through the portal from LINE ITEMS, I want to be able to create new records in the PRODUCTS table, should they not exist already. Obviously, the easy solution (for me) would be to simply fill out the PRODUCTS table beforehand and have the users call them up when needed. But catalog numbers and prices change with time, and I'd like my database to reflect that. Furthermore, the vendor is important as an identifier for PRODUCTS because there is the possibility (however small) that two vendors are using the same catalog number for different products. Anyhow, if anyone could help me with this, that would be great. Joel
  4. To answer your question re: vendor restrictions, due to a quirk in the administration here, we are limited to one vendor per requisition. Therfore, I make the vendor one of the parent fields in the main table. I've set it to a custom value list, with the possibility of adding entries. So my question is thus; if I want to be able to enter all data from the main form (new names, new accounts, new vendors, new products, et cetera). How can I arrange my relationships in order for that to occur? I can't create new records through a relationship where the match field doesn't exist yet (or can I? I've managed to do this with names & associated information, but with the line items/products tables, it seems quite a bit more difficult). Joel
  5. The attachment won't download properly?
  6. I tried to sneak it past the value sorter by placing the a numeric order before the text string and blanking out the order by fonting it as white. No dice. Anyhow, I've decided to just go ahead with a two field value list as slimjim mentioned.
  7. Is there a way to change the order of a value list when defining from a field? Let's take for example; Table "Blah" NAMES JIMMY BOBBY RAUL ANDY a value list defined by NAMES from Table "BLAH" will come up in the pop up list like ANDY BOBBY JIMMY RAUL .. is there a way to enforce the order listed in the field as the order that the values come up in the list? Or is the alphanumeric sorting undoable in filemaker? Thanks, Joel
  8. You don't have to repeat the same values, unless you're using a lookup, which copies data from one table to another. If the tables are related, you can simply put the FOREIGN table's fields in the PRIMARY table's layout (using the INSERT FIELD function). When you INSERT a field, you'll get a menu that will allow you to select from the current table and all related ones. Pick the table you desire, and then select the field that you want to be represented on your report. Hope that helps. Joel
  9. From what I understand, you'd have two tables, one to describe the sample, the other the position. Then you'd have the following setup: SAMPLE......................POSITION
  10. Understood, but I want to limit the column / row selections to existing values. As in, someone can't type in "row 1, column 3" for a pie box, because such a location does not exist.
  11. I'm building an inventory database for our lab, specifically regarding the storage of cell culture samples in liquid nitrogen. I've got some familiarity with database design and normality, and was wondering if I could put the functionality of Filemaker to work for me. There are two containers for these samples. They contain varying numbers of racks, and these racks contain a fixed number of boxes, and these boxes have different layouts (all depending on the container, essentially). Here's a basic overview; Container 1 Has 6 racks Each rack has 12 boxes Each box has a "pie" shape, which looks like this: XX XX XXXX XXXX XXXXXX XXXXXXXX XXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXX XX Each "X" represents a sample (or a blank space). Container 2 Has 4 racks Each rack has 11 boxes Each box is arranged in a simple 9 x 9 array. I was thinking of making a "Containers" table with the following fields... ContainerID Name Racks Boxes For each record (each container), I was thinking of just listing out the numbers in the racks/boxes fields.. for example (Container 1) RACKS ONE TWO ... SIX BOXES ONE TWO THREE ... TWELVE And having a conditional value list identifying the location of a Sample based on those fields. However, identifying the specific location of the sample within the boxes is more difficult, because there are two different box types. Furthermore, one of those box types doesn't have any mathematically sensible pattern (so far as I know), so my initial idea of having serial identifiers for sample position and basing its row and column coordinates on some sort of calculation is out the window (as far as I know). My idea was to have a conditional value list (Column) based on another conditional value list (Row/Boxtype) which, in turn, would depend on the type of box the samples are located in. Is this possible? Is my logic sensible? Alternately, I could just put in a graphic and employ a serial numbering system (with the graphic identifying the specific position). That, obviously, would be simpler. But I'm trying to make it easier on the user end. Any recommendations? Joel
×
×
  • Create New...

Important Information

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