2 Replies Latest reply on Jun 14, 2011 9:01 AM by aammondd

    FoxPro to FM Advice



      FoxPro to FM Advice


      In the mid 80s I wrote a series of programs using FoxPro for my sole practitioner law office to keep tract of my clients and accounts receivable (basically an accounting program). I have it running on Visual FoxPro using Parallels on my mac. Except for changes made in 1999 for year 2000, the database structure and programs (which were not rewritten for VFP) are what I originally wrote (mainly using my then dBase knowledge). In other words, it looks like an old dBase program.

      I am thinking about rewriting the programs using FM. My question is how difficult it will be to convert the databases. I set it up using one relational main database and several other sub-databases.

      And, are there any programs out there that will take a dBase or FoxPro program and convert the program to FM? Or am I better off, as I suspect, learning FM and converting my old FoxPro databases.

      Any help would be most appreciated.


        • 1. Re: FoxPro to FM Advice

          You can move the data from one system to the other, but the relationships, screens, etc would need to be redesigned and re-created in FileMaker. I believe Fox Pro stores the data as DBF files. FileMaker can import directly from DBF files--so that may be one way to move the data, but certain dbf files--such as memo fields don't import with complete success so you may have better luck exporting to a text file such as a tab or csv file and then importing into FileMaker.

          • 2. Re: FoxPro to FM Advice

            You will probably find FMP very alien in some ways to the way you are used to.

            FM doesnt do queries in the traditional sense. 

            For many things in FM you establish the relational structure of your database in a fairly static state. You can create as many of these "Joins" as you like as Relationships. These become very useful in designing forms and working with the data.

            FM's unique approach to relational databases also gives you some extremely powerful and flexible tools. In some ways this is its shortfall too. Rather than forcing you into good/traditional relational database design the tool allows you to be more open ended to achieve what you want to accomplish. Once you begin to understand  the differences you will find powerful ways to do things quickly that your other solutions would have required extensive coding or simply not been possible.

            If you spend some time mapping the relational structure of your existing solution it will go a long way to helping you establish a good base for making the switch. Some things you do in one solution are completely different and often not needed in FM due to the overall approach the FM takes.

            Queries and Finds are not simply synonymous.