Jump to content
Sign in to follow this  
Munchie

Thought I was getting good untill I started w/FM7

Recommended Posts

Tonight, I began my first database in FM7. I had started this DB sometime ago in FM6, and thought I should start looking into 7. A few issues that I quickly became stumped by.

1: I wanted to import some sample data into my tables in order to see how it works. From File/Import/File, I could not get it to change what table I was importing to. I even created a new layout that only had fields from that particular table. I would not give any option to import from, except my main DB. I got around this by creating a script, however, I would like to know better how this works.

2: Creating a new record script step. How do I script which table I'm creating the new record in? My example: I have the MAIN database, which will contain mostly personal information. I have a field that has the latests "notes." When I click the field, It gives me a dialog, and asks me for the latest changes. The script takes the previous notes, and puts it into another table, and saves the current note in the field. In FM6, I did this saving the data I wanted to Global fields, then running a script in the related file. In FM7, it's the same file, different table. If I say New Record/Request, it will create the record in the MAIN Table, not the NOTES Table. This doesn't make much sense to me.

3: Everytime I click on an empty layout area, the DB seems to stall for a second. What's that all about?

Thanks to the help anyone can offer on any of these issues.

Share this post


Link to post
Share on other sites

1. Did you notice the "Source:" drop-down menu at the top-left of the field list in the Import dialog? That's where you choose the Table Occurrence you will be importing from. You have to be ON a layout attached to a Table Occurrence tied to the "base table" you want to import into.

Table Occurrence (TO) is a new thing in 7; what you see on the Relationship Graph. It is tied to a particular base table, but can be filtered by a relationship. Almost all of your layouts are going to be tied to one these base table TO's (one is created for you when you create a Table); all layouts are tied to one particular TO. The reason I bring this up right away is what you see in the drop-down menu in Import is TO names, NOT base tables names.

2. Same basic problem with New Record. You want to go to a layout which is tied to the base table where you want a new record. In this case you'd be choosing a layout name.

It's critical that you name a TO or layout so you can see to which base table it is tied. Because those are the names you are asked to choose from.

On the plus side, you don't have to switch files, it can all be easily done in one script. You also no longer need a Constant relationship to pass globals. Just reference a plain TO of the other table to get its global field; or pass from there to where you want it to go. Remember where you are at all times.

3. Be sure to upgrade to 7.0v3. Earlier versions had layout glitches. Otherwise I'm not sure exactly what's going on.

Share this post


Link to post
Share on other sites

Fenton,

Thanks for the response. On the Import, I did see the drop down when I imported as a script step. However, it did not appear when I did it as a manual import. File/Import/File. I found it frustrating that I had to write a script to get it to work.

I'm guessing that the New Record will work the same way, and I'm concerned that I'll get unpredictable results the way I think I have to do it.

I do have the update installed. I saw the appearance difference when I did that.

I feel like I lost some control with the new Table format. When I created a totaly new layout with only 1 tables fields on it, I attempted to do the manual import, and it still gave me the Main Table to import to. I'm nervous that this will hold true with New Records, and other steps in my scripts.

Another issue I see coming up when I begin converting my other big project, is many of my layouts have multiple relationships and scripts for all kinds of differnt tasks on single layouts.

Again, thanks for all of your help.

Share this post


Link to post
Share on other sites

AHHHHH!!! I finaly found a reason to goto the Setup Layout dialog, and found some new toys to play with!! Kewl.

Share this post


Link to post
Share on other sites

I think you're worrying a little more than necessary. It works. You can always choose which table to import FROM. You may have just not noticed that drop-down. It's easy to forget it's there. You have be ON a layout for the table you want to import INTO.

New Record, same thing. You have to be ON the right layout. But you can go to the layout in your script, create a new record, then go wherever else; all in the same script. No more jumping around to scripts in other files. Even if the tables are in separate files, you can put a Table Occurrence (TO) of the other file in your graph, and you're good to go.

Yes, there's some conversion issues.

1. Bunch of old and flakey file references in your version 6, made visible in 7. There is a commercial tool to fix this. Worth it on large solutions for sure; main cause of slow operations.

2. Some differences in the way 7 makes layouts visible. By default many steps which used to always show the layout (because in 6 there was only 1 layout/window per file) don't necessarily in 7. This is good. But, on conversion, 7 adds Select Window steps here and there, to make it behave like 6. Often you don't need/want them. Sometimes you do though (navigation to end up somewhere).

But using all kinds of relationships, etc., on one layout; there's no problem. It works the same. Just make sure your layout is using a "base table," and not some odd TO, which does not have access to other TO's. It's a good idea to look at the Relationship Graph when there's a question. The lines don't lie.

Sometimes you have to create another occurrence of a base table, dangling off the end of a TO Group (a bunch of related TOs), to solve the "you can't get there from here" problem. But, realistically, we had to do this in 6 also. That's why we had so many relationships.

It's better in 7 though, because you can often read "through" intermediate TOs. Relationships are not limited to just the "adjacent" TO. This solves most of those "data tunneling" problems (if you CAN get there from here ???-)

Share this post


Link to post
Share on other sites

Hey Fenton,

Thanks for your help. I've been getting a lot more done as I see the things you're talking about. I've attached an image of the box I'm talking about. Based on the way you're talking, I'm wondering if you haven't seen what I'm talking about on the import dialog. It only has the drop down for me on the import script step. I have solved my issue with the Layout Setup options.

Seems strange that it wouldn't allow me to select the relationship to import to on the File/Import/File option.

Again, Thanks for everything!

Import.JPG

Share this post


Link to post
Share on other sites

You might take a look at a whole bunch of FM7 whitepapers available on the FileMaker web site. They are helpful in describing the differences between FM7 and previous versions. They also offer an extensive discussion of conversion issues.

-bd

Share this post


Link to post
Share on other sites

It can choose which table to import FROM in another file, because it is only reading data. But it can only import INTO the current table; because it's writing data (I don't know the technical details, but that's my understanding of it). Think of Go To Layout as "choose the table."

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.