Jump to content

barkingsheltie

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About barkingsheltie

  • Rank
    novice
  1. Thank you mfero. I thought about what you said today towards the end of my day, and please know your comments have given me pause for consideration. Both of you shared enough insight, especially the last comments you made, that not only do I feel confident I can deliver a better solution now that I would have previously, I think my filemaker/database skills have been upped a bit too in the process. Thank you both! Shelley
  2. One last, Would it be worthwhile to use an interface layout, 1 record, as opposed to doing everything on the main table, e.g., user could fill in customer, model type, date, and then initiate new serial # script which would grab relevant info and then commit record to new table? Like most of the multi-user scenarios I've seen. I like that, in the event some hiccup occurs, and seems to me the id for the main table should be the serial number sequence, without the suffix of course.
  3. Thanks mfero and comment. Asked my boss, he thinks that's great. The person that stamps them is confused, but I think when he sees the database in action, it will be fairly straightforward. I like just using the A, B, Suffix, as it will be easier for searching. Im sure you could easily get around with script, formatting, but just seems easier to me to add suffix. Thanks again for the quick and helpful suggestions.
  4. Prob not...hmmmm. However, quite a few records and thus overlap with previous instances. 20k records for greatest sold product, 10k for next, etc. One reason there wasn't more differentiation with serial numbers, is these are physically stamped onto cast aluminum body of the products, and its time consuming, tedious, so long numbers were discouraged.
  5. Thanks! If I understand you right, within the consolidated table, when the user requests new record, they could be queried for model type for instance, and then the script could go to a TO (this would be the selfjoin you mention) and filter only those records for that family (match field), and after sort, descending, voila, the necessary data for incrementing. You would have x # of selfjoins (TO) as you have families. If I understand you right, that is perfect, thanks for helping me. shelley
  6. Possibly. Always hard to know exactly which forum to post such. Im looking to get insight/impressions by others. Not a newbie, but not an expert like a bunch of smart folks here. Im updating a database we use to keep track of serial numbers for products we sell, and in addition we receive some of these products back for service. Its useful to keep track of when/how many times a product has been serviced. The service database is separate from the serial database. Right now, we have separate tables to track each different product serial number - for example, widget A starts
  7. In the event anyone is monitoring this thread - great stuff. Fun reading. I recently began redesigning an old product inventory db that we use alongside our client/server accounting system. The latter doesn't have BOM and the ability to attach a cad pdf, process sheet, etc. I implemented a test version for Mr. Graham's technique; seems well suited for our needs. Works well. Does it make sense to do this in reverse? Create a new record in parent/inner table, then create related record in outer table via the portal key - though this time the 'create related record' would be en
  8. Thanks! By design challenges, I should rephrase - as I plan, continue to extend and implement this database, I wondered whether there would be any advantage(s) of using pn's as primary keys down the road. The primary challenge faced right now, is coming up with a search algorithm/process that can account for misspellings, partial matches, flawed input from customer, etc. Im more versed in command-line c programming, and I know I need to get away from methods I might use there, and learn how to do this the *filemaker* way. In any case, I appreciate the advice & experienc
  9. I have a table that contains part numbers for contacts, connectors from hundreds of manufacturers. Via a line items table (called cross-ref), we use a relationship to match tooling and accessories we manufacture. Unfortunately, there is no consistent nomenclature scheme for these, eg, Company A has A445-2cX13.0-2, and another NSN-5120-00-23-5441 and so forth. Initially, the primary keys in the various tables used record id's, of the type that were auto-enter. A few design challenges got me to wondering if things might be easier if instead of record id as key, I made use of the part
  10. Yep - that helps alot. Thanks. I will tinker with this some over the weekend and on monday - the file tells me how I was either missing how to normalize my tables and expand the main table into appropriate child tables. Thanks :thumbup:
  11. 39 views and no replies! My writeup was probably poorly written - and I don't mean to ask for someone to design this for me - although Im open to anyone who want's to consult for a reasonable fee. Maybe if someone could point me to material/tips related to complex many to many relationships that my problem *seems* to suggest - I believe I understand the normal parent-child and sub-child methods that are used for instance in invoicing, order entry situations. Maybe the way to tackle my problem is too split the inventory into sub-groups (child), and then use a join operation to a
  12. I want to redesign a pretty simple cross-reference db that we use here at work. Its a very simple flat file, one table beast at the moment. A little history will possible shed light on matters: We make crimping tools for use on electrical contacts that are used in a variety of connectors. There are over 1,000,000 contact part #'s worldwide - we have identified some 50k numbers, linking them to various tooling we manufacture. Our simple table has the connector company, part number, size, etc, and then the remaining columns, about 14, which are used to denote our tooling tha
  13. Thanks again. Your suggestions have put me on track to at least try these out in filemaker. Its not that hard to test things out for the php/mysql method as well, and then hopefully the *best* solution will be somewhat clear.
  14. Thanks for the tips, including the links. I will take a closer look and see if these will work for me. Converting to a number (I assume GetAsNumber(data) is the function you are thinking of). This will at least produce some matches - given that often its the spaces, and formatting characters, /,-, etc). At the risk of asking for too much indulgence - the little I know of php and/or c, would be to copy the contents to a temp array, while using a function to strip out all the non number, alpha characters, and then something like the Levenshtein method, or a lame concoction of my own c
  15. When there is not an exact match for a find, is it possible to do a 'fuzzy' search, say something like a Levenshtein edit distance threshold on alphanumeric strings? I have an application/need, a 'cross-ref' list which has connector industry part #'s that are cross-ref to our products. Often a call/request will not have an exact match for the part number, e.g., M39029-13 and the correct part number is M39029/13 (its not just misplaced '/', '-', '', etc, but also situations like, MS24256A requested, but actual is MS24256B. These examples had the differences tacked onto the end, but it c
×
×
  • Create New...

Important Information

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