4 Replies Latest reply on Jun 12, 2014 9:26 AM by marksystech

    FMP13 - A few questions

    marksystech

      Title

      FMP13 - A few questions

      Post

           Hello All,

           My client is using older FM5 and we are updating them to FM13.  We have decided to rebuild the files and import data rather than to try and convert based on input from this forum.  Thanks to everyone that replied.

           I have a couple basic questions that hopefully will help me to decide the path to follow:

           1) When you install FMP13 they give you a very nice "Getting Started" example.   I would like to unlock that database and examine the scripts and layouts however when I go to manage it says I do not have rights?   Is there a password I need?  I'm particularly interested in how the file was setup to present the nice menu.  

           2) User privileges.   I know FMP has built in rights, right sets, etc.   For this customer I am going to need to allow some people to see a particular layout, others cannot, they will have to go to a different layout.  The idea is that some people should not be able to access/change some table fields (such as is a vendor approved or not).   Is the best way to do this using the built in rights and setting up different views/layouts or would it be a good idea to create a "user" table and store some of that data in there?   Adding to this I have to say the client wants some email triggers so somewhere I will need to store user info with an email.   IE if a PO is created for more than $xxx the office manager would love an automatic email, etc.   Any advice on "users" and rights/security would be much appreciated.

           3) Locking/protecting both tables and layouts.  This company is ISO based so things need to follow their procedures and as such many things are "approved documents" including the FM tables and layouts.   I know FM has a locking feature but in general what do FileMaker people general do for table/layout versioning and tracking?

           4) Last question - Export/import.  As mentioned above their structures are very old however the data is very valuable.  My plan is to recreate many of the structures in FMP13 and import their old data in place.  However there needs to be some changes.  For example in one older table they have a "notes" field.  Their people are used to erasing and putting in new notes but their ISO requires archiving.  So my plan is to have a related notes table.   When importing their data I need to take whatever is in the "notes" field and create a new record in the notes table with that data.  This sounds and seems like a script.  I've not tried to do export/import with FM scripts.  I assume what I need to do can be done and if not do people general export, run some external process to separate out the data (like "notes" in this case) into a different file, then simply use FMP import?   What is the best approach consider we need to preserve everything but the new FMP13 structure will be changing in some places?

           Thanks so much in advance.

        • 1. Re: FMP13 - A few questions
          philmodjunk

               1) What is the exact message that you get. If you get a message that the "file is not modifiable", the file needs to be copied to a location, such as your desktop, where your computer user account (not FileMaker) gives you "write permission". If you don't know where this file is, you can probably use save a copy as... to save a copy to your desktop and then you can double click that copy to open it. There is also a "new from starter solution" option that can create a number of different example files for which you will have full access to.

               2) I suggest that you see "Editing record access privileges" in FileMaker Help. After reading that section, you'll have a better idea how this works and you can ask follow up questions from that context.

               3) I'm not really clear on what you really need here for this even though I am familiar with ISO policies and procedures. Last place where I worked that had this, the auditors we had never asked about version control for the design of the databases where we managed our documents, only that we had proper version control and documented review and approval processes for the data contained by the database. But I suppose that a document control database could treat itself as one of the documents to be controlled.

               4) I don't see the need for a script from what you describe. Since this is a one time process, it looks like a straight manual import of this data--as long as there is a value to use as the foreign key field for linking to the original record's primary key can do this just as well and saves you the time needed to design a script--that would use the same dialogs for setting up a scripted import that you'd use for your manual import. But there could be design details that you haven't described that make this a less straight forward import than it seems.

          • 2. Re: FMP13 - A few questions
            marksystech

                 Hello PhilModJunk,

                 Thanks for the info:

                 1) I get no message except if I can get to File->Manage->??? I will some times get that I don't have rights to access this.  I did try save copy as and opened the copy however every selection in File->Manage->??? is grayed out.

                 2) I will study the help and had planned to.   

                 3) It can be as simple as a screen shot of the table structure and the layout then the QA person assigns a number.  I was just curious if anyone was doing anything more elaborate such as versioning within a version table.  IE if I had a version table I could enter a document key, an approval number and then when a layout is shown, display the data from the version table.  May be more than they need, but just wondering if anyone is doing anything cool/different that might work better for these guys.

                 4) I have not fleshed out the design fully yet so perhaps best to ask this as I get further along.   I am used to SQL exports where you can extract the data and with a few short commands vector some of it to different places.  I'll just have to play around and see what works best.    As far as it being a one time, I think it actually may be a two or three times.  IE they are probably gonna keep working in the old system, I'll do a export/import, text functionality in FMP13, then let them run a few tests and I'll probably have to zero the tables then transfer again with more updates, etc.  At some point we will flip the switch and they will go live on the new system but I do expect to do one or two xfers.

                 Thank you so much for your input.  I will keep studying help, idea, forums and will ask questions when it makes sense.  I used FM for years.  This however will be the first time I've tried to convert really old to really new. 

            • 3. Re: FMP13 - A few questions
              philmodjunk

                   3) Yes, but with ISO document control, you should already have a document control database and this same database can be used to track version control for the database or significant parts of it just like you would any other document.

              • 4. Re: FMP13 - A few questions
                marksystech

                     3) That is what I'm pushing them to do.  Just wondered if people were doing something more elaborate.   I am a member of a team on a very large SQL Server database and there is a document control table that does more than just store approvals and numbers.  It actually contains some SQL used to validate the other tables and that they have not been modified.   Anyway I am going to push them to use at least at first a table for this purpose and they can grow with it as needs change.

                     Thanks again!