Jump to content
Sign in to follow this  
Tissot

Serial-Nr. Problem!

Recommended Posts

Hello!

I've got a small Problem.

I've got 4 Tables for 4 Different Invoice Layouts and I need to somehow create one Serial Number for all Tables.

Basically one Serial Number spread across 4 Tables.

Thanks for youre reply!

Share this post


Link to post
Share on other sites

Make three of the serial number fields calculation fields based on the serial number field in the first table.

Share this post


Link to post
Share on other sites

I wonder why you have 4 tables for invoices. Couldn't you have the four layouts in one table.

Share this post


Link to post
Share on other sites

Why do you have different tables for the invoices? Why not just have one table for invoices and have all 4 layouts represent the same base table? I'd imagine that most of the fields would be the same, and you would just have one field that would differentiate between the 4 different situtations.

Share this post


Link to post
Share on other sites

But they're all invoices right? What makes them different?

Share this post


Link to post
Share on other sites

One is for Time Invoicing, another is for Material, etc... there's no way out of not having 4 Tables for this Application.

Share this post


Link to post
Share on other sites

One is for Time Invoicing, another is for Material, etc... there's no way out of not having 4 Tables for this Application.

Unless you have a compelling reason to keep them separate, it is usually better to have like-data in the same table. It would certainly solve your serial number problem.

Combining these tables does not force you to access them from one portal, if that's what you're worried about. You can use another field to differentiate the data, and include that in the relationship:

'Invoice->Line Items Materials' relationship:

Invoice::Invoice# = Line Items::Invoice#

AND Invoice::gTypeMaterials = Line Item::Line Item Type

'Invoice->Line Items Labor' relationship:

Invoice::Invoice# = Line Items::Invoice#

AND Invoice::gTypeLabor = Line Item::Line Item Type

So four global Type fields in the Invoice table, one Line Item Type in Line Items, and four table occurances for the relationships should work.

Share this post


Link to post
Share on other sites

I don't know if you've finished your solution yet.

You could have a central table that had the common fields that all invoice types shared, then create a related table for each layout type. Since you don't have to use a portal to access related field in other tables, each layout would be simple to create.

Share this post


Link to post
Share on other sites

Thanks!

The best solution is a Global field and tell Script to +1 each time you clik new!

Cya

Share this post


Link to post
Share on other sites

The best solution is a Global field and tell Script to +1 each time you clik new!

This could be problematic in a multiuser environment, as each workstation keeps its own copy of globals that are only available to that workstation's current session.

Share this post


Link to post
Share on other sites

I see so how would you proceed ?

Can some one make me a smal sample ?

Thanks in advance !

Share this post


Link to post
Share on other sites

I still recommend combining your tables into one. You haven't given a good reason not to.

But were there a good reason, you could use the Last() function to see the last serial number used from each table, then set the new serial number to be 1 greater than the highest one (each Last(Table::Serial) function would need to look at a table occurance based on a cartesian join(X) relationship.) This still has a possiblitiy of two users creating a record at the same time and getting the same next serial number.

Share this post


Link to post
Share on other sites

I've still got a BIG Problem ! PLEASE Help!!!

Is there a simple way to do such a thing?

Because the Global field doesnt work! (duplycates)

Central Tabel ? or....

Please Help!

Thanks bigtime in advance!

Share this post


Link to post
Share on other sites

I've been lurking for a few weeks and am amazed at what you guys here do. Since I'm gonna be needing lots of help in the coming months, I decided to start posting. laugh.gif

I think I have a similar problem.

I'm making a solution which involves 5 different companies of our group, 3 of which do exactly the same work (cargo transport), 1 does maintenance and the other real estate. So, for instance, I have Purchase Orders on a single table but need it to auto-enter serial numbers for each company. Anyone have any pointers on how to achieve this?

Also, I've grouped info by area i.e. Administrative, Operations, Maintenance and accounting; each with its number of tables and layouts. Should I cram all these into a single file or create a file for each area? What would the pros and cons be? We have 10 users (both Macs and PC FMP7)and FMP Server 7. I created our current solution 10 years ago and its been growing over the years to the point i have a mess of unused layouts and fields. So I'm forcing myself to upgrade to FMP7 to redo everything and add new tables (accounting ~shivers~) and all this in Spanish.

Any and all help appreciated

Share this post


Link to post
Share on other sites

But were there a good reason, you could use the Last() function to see the last serial number used from each table, then set the new serial number to be 1 greater than the highest one (each Last(Table::Serial) function would need to look at a table occurance based on a cartesian join(X) relationship.) This still has a possiblitiy of two users creating a record at the same time and getting the same next serial number.

Can you or some one explane how to do this ? or make me a simple sample?

Thanks in advance!

Share this post


Link to post
Share on other sites

Is there any way els to have a serial number across 4 Tabels than a Global field ?

Global field version dosent work (I alwys get duplycates)

PLEASE HELP ME OUT OF THIS MESS! blush.gif

Thanks ever so much! wink.gif

Share this post


Link to post
Share on other sites

Create a table that is related to all the necessary tables via a constant calculation field of 1. Create a serial and global field for this table and one record in the table. Enter your next serial into the serial field. Create a script

Set Field [global; serial]

Set Field [serial; serial + 1] {If you need to add leading zeroes, use Right( "000" & serial + 1; 4 ) or something similar, depending on how many zeroes you require.}

Call this script each time you create a new record, then Set Field [yourtable::serial; constant_relationship::global].

Share this post


Link to post
Share on other sites

One is for Time Invoicing, another is for Material, etc... there's no way out of not having 4 Tables for this Application.

Why do you need the same Serial No for different Tables? Do you want expose it to users? What for?

Share this post


Link to post
Share on other sites

Actually, you can use a simple cartesian relationship for this. And the constant table only needs to have one record. You can use GetNextSerialValue and Set Next Serial Value to update it. You only need one script; you can use script parameters to determine which field to set.

See attachment for modifications.

SerialProblem.zip

Share this post


Link to post
Share on other sites

Thanks now I understand.

Could this solution cause Duplicates?

Thanks for your answer.

Sincerely

Share this post


Link to post
Share on other sites

Yes, anytime a serial is not auto-entered immediately upon record creation, there is a possibility for duplicates, which is one reason this sort of setup is not very good design. I'll elaborate later when my mom isn't talking my ear off on the phone for half an hour. wink.gif

Share this post


Link to post
Share on other sites

Duplicates would be possible in a multi-user situation; unless you lock the record. I've included a little example of what it would look like. No guarantees, but I think it'll stop duplicates.

SerialProblem2.zip

Share this post


Link to post
Share on other sites

Works great thanks!

I made about 200 new Records in a random way with two machines and no dupes!!!

I think this string will be quiet from now on :-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • By Tony Morosco
      I'm a botanist, and the tables I am working with are for tracking botanical garden collections. The data represents plants in the garden, and the plants are tagged and show up in the database.  The tables I am working with were created in FMP 7, and I'd like to open them up in FMP 11 (or later.)  The system hasn't been used in years, but still has valuable information.
      One of the tables is giving me problems using the FMP convert and recover commands.
      These tables are all inter-related.  The main table is the Accessions table, which contains records for all of one kind of plant, from the same source, received on the same date.  It is basically a museum standard.
      The other tables are related to each other through this one main table.  The Species table is related to the locations table through the Accessions table. 
      (i.e.  table A relates to table C through the table B, the intermediary)  
      From the Locations table, we can't see the the species information unless the accessions table is present.
      When issuing the open command on the main table to convert the database to FMP 11, I get the message:
      "Accessions.fmp7" is damaged and cannot be opened.  Use the Recover command to recover this file. When using the Recover command from v. 11, I get another message:
      WARNING: problems were detected while recovering the database.  Please review the Recover.log file to see where problems were found and their severity.  The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file. Recovery results:   File blocks: scanned and rebuilt 563 blocks, dropped 214 invalid data blocks.   Schema: scanned fields and tables, 1 items modified   Structure: scanned; 1 items modified   Field indexes: rebuilt  
      Opening the recovered database, there are only three records present.  There should be hundreds.  So obviously I am looking on how to wrangle this database open.
      I've attached the log file here, as well as the database structure map.  
      The other files have converted just fine.  But since the main table won't open, we are kind of stuck.
      I can share the files with you through Dropbox or whatever, if needed.
      Please let me know any thoughts you have, either basic or advanced.  And ask for any clarifications or additional questions.   :-)  
      Thanks!
      -Tony
      Recover.log

    • By Tumma K
      Hello, All!

      I am an aspiring developer for Filemaker. The company I work with is stuck in the past working off of Filemaker Pro 4.1

      I was given the task of bringing us up to Filemaker Pro/Server 13. So far my conversion prototypes are successful but we recently had a layout issue that can only be fixed in versions 3-6 (as the file is an .fp3) I work off of a macbook while our network is all Windows 7. In order for me to repair the layouts without tampering our active database, I decided the best option is to repair a copy of our solutions off the network. Unfortunately, when I go to download the trial version of Filemaker Pro 6 off of the respected website, the file is corrupt! I've tried multiple times, with different extraction apps and in different directories.

      My question is;

      Does anyone know a place where I could obtain version 6 (or better yet, 4.0) for an OSX computer? I've looked everywhere!
       
      Thank you for your time,
      Tumma K.
    • By MrEddByrnes
      I'm hoping my question can have a happy ending. In the mid-90's, I purchased Filemaker 3. When Filemaker 5.5 Pro was released, I bought the update CD, which requires the user to either have FM 3 installed or to have the installation CD for FM 3. I've used it all these years, most recently with Windows XP Pro, and it has worked just fine. The databases I began with were long ago converted to FM Pro 5.5 databases.
       
      I'm still using FM Pro 5.5 on a laptop with WinXP Pro, but in 2013, I purchased a PC with Windows 8. I haven't been able to install FM 3 on it, therefore can't install FM Pro 5.5. I am retired and rarely use Filemaker, but I have a few Filemaker databases I'd like to add to my Win 8 machine. I don't feel it's worth upgrading FM for the sake of using a couple of databases.
       
      Has anyone else run into this situation and/or have a (possible) solution? Is there perhaps any other software that can read FM 5.5 databases? Thanks in advance for your help.
       
    • By bmill
      I am using a custom filemaker solution for medical office billing written with fp5 running on a mac with snow leopard. In addition, I have a patient management db (which I wrote) that is linked through pt. ID number to the billing program allowing transfer of some demographic information (name, DOB, etc).
       
      Other than being limited by hardware restrictions, the billing program serves our needs for now and upgrading to fp12 will take some time (and money).  In the meantime, I am upgrading my pt. management program to fp13 and would like to move new patient demographic information from the billing program ( fp5 running on snow leopard through Parallels) and the new pt management program ( fp13 running on OS X 10.9) on the same mac.   
       
      Ideally, demographic information would be entered once into fp5 and then a scipt would make the data available for fp13.
       
      Any ideas on how to make this work?
    • By randyinla
      Hi, can anyone tell me why my on-line database might have stopped allowing me to delete records?  All of my access privileges and passwords are correct.
       
      thanks!
×

Important Information

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