7 Replies Latest reply on Oct 8, 2012 1:05 PM by philmodjunk

    Building off Invoice Starter Solutions

    pad-man

      Title

      Building off Invoice Starter Solutions

      Post

           After some good advice here I have taken the time to go through a few of the tutorials and start my learning curve. After watching I certainly can use the invoice solution provided with FMP Starter solutions. What are the pitfalls or problems if I use this and then add to it my tables an then create the relationships from the already existing from the Inovice Starter? Or an I better off trying to build the table and relationship structure copying the customer structure, making textual edits to fields and then slowly add the tables as suggested in the tutorials. Meaning add my tables in addition to Customers, then create the relationships with the new tables, then enter fileds I need for the tables after the relationships are made.

           Thanks in advance for your time and consideration.

            

           Adam

        • 1. Re: Building off Invoice Starter Solutions
          philmodjunk

               There's no simple answer to that as much depends on how extensively you need to modify the starter solution and what skill level you bring to the task. Generally speaking these starter solutions are intended to be modified and starting from one of them can save time getting the basic setup up and working, but also sticks you with the orignator's approach to naming conventions and layout design.

          • 2. Re: Building off Invoice Starter Solutions
            pad-man

                 I do not have any programming background and same for scripts. I am looking to build a single user DB. Currently using Quickbooks for MAc to handle my invoicing. I don't inventory an products. The bulk of my business is service oriented but I do have over 100 products in my ecommerce. So I don't know enough about the Invoice Starter solution. I am thinking perhaps I should try building my  5 table DB create the relationships on my own and then recrete it by adding it to the invoice solution.

            • 3. Re: Building off Invoice Starter Solutions
              philmodjunk

                   Once you have built your own relationships, why need to add it to the starter solution? You may find that your "from scratch" solution does everything that you need without having to merge any of it with the starter solution.

              • 4. Re: Building off Invoice Starter Solutions
                pad-man

                     I think you may be right! I started with the Contacts and Personnel Solutions. As soon as I started to delete the fields I was not going to use I started to get messages like "_____" is used in the script "find similar ______" Proceed anyway? If I do continue using a starter solution and get these messages is there a place where Ic an delte the corresponding script, or it's just not that easy?

                • 5. Re: Building off Invoice Starter Solutions
                  philmodjunk

                       I would recommend acquiring FileMaker Advanced. There are several design tools in it that save the developer a lot of time and frustration. One of the tools in it is a database design report where you can track down all references to a field--in layouts, scripts, calculations so that you an determine whether or not you can remove it and what parts of the database may need to be either removed or modified as a result.

                  • 6. Re: Building off Invoice Starter Solutions
                    pad-man

                         Thanks for the advice on the advanced. Sorry if these questions are way below the level you are used to aswering. In staring from scratch, as you previously advised, does every table need to have a key? If one table is a child and I have listed that table as a forieng key in the parent table, is it possible for the child table not to have any key listed as a field in the child table?

                    • 7. Re: Building off Invoice Starter Solutions
                      philmodjunk

                           This is a forum mainly in place to help new users of the product so your questions aren't at all below the level I am used to answering.

                           Many developers strongly recommend that you add a primary key to every table you define in your database. An auto-entered serial number field is used for this purpose in almost every case in FileMaker systems, though some now experiment with using Get (UUID) as an auto-enter calculation instead.

                           I recommend that but leave off the "strongly". They aren't needed in every single table and adding a primary key at a later point in time should I find that I need one is very, very easy to do in FileMaker. (Add the field, then use Replace Field Contents with the serial number option to add serial numbers to all existing records in the table.)

                           I'm also not thrilled with the MATCH FIELD naming convention used in the starter solutions. I find it very cumbersome. Instead I name a primary key as:

                           __pkTableNameID

                           and foreign keys as:

                           _fkTableNameID

                           The underscores cause the fields to alphabetically sort to the beginning of lists and the two underscores for primary keys make sure that they list ahead of foreign keys.