7 Replies Latest reply on Jan 24, 2011 2:47 PM by Sorbsbuster

    Interact with FP7 files programmatically

    DevinGoble

      Title

      Interact with FP7 files programmatically

      Post

      I periodically need to exchange data with someone who uses FM Pro. I'm currently trying to get them to accept a CSV file, but they aren't very flexible because of "The Process".

      In the meantime, what are my options for being able to read/write an FP7 file without having FM installed on the server? I have a copy of FM Pro and I've been playing around with the ODBC driver. However it seems that I can only access the database from ODBC when FM is running?

      Any thoughts would be appreciated.

        • 1. Re: Interact with FP7 files programmatically
          Sorbsbuster

          An FM client will happily import from / export to a CSV file (and many other useful formats).

          When you want to send them data you can generate a csv file, send it to them (or 'make it accessible to them') and they should be able to write a very simple script to import that data.

          When you want to receive data from them they should be able to write a  very simple script to export that data to a csv or merge file, say, and make it accessible to you to use.

          You don't need to have FM Server, or FM installed on your 'file serving computer' to do any of that.  They could easily, for example, generate the csv file and e-mail it to you as an attachment.  Or save it to a default destination on your fileserver from where you could pick it up.  (And, presumably, vice versa.)

          If the location of your data is accessible via ODBC then FM can interact with it directly, no need for csv-file exchanges.

          • 2. Re: Interact with FP7 files programmatically
            DevinGoble

            I just heard back from the people I exchange data with, and unfortunately "The Process" wins. They are therefore unwilling, or unable, to accept their data as anything other than an FP7 file. We have no network connectivity between the two of us, so anything of that sort is out the window.

            The architecture is that there are a couple of people on my end that use an FM runtime application that exports FP7 files to be sent to the other party. Recently we've had a need to start capturing that data for our own purposes. That's led to a project to develop our own application, but still with the requirement that we export FP7 files.

            I can use a blank copy of the current export file and just put data into it, but I need some way to do this programmatically. It needs to be automated for a number of reasons. My real problem with this is that I can't figure out a way to do this without having an instance of FM running. Is there another ODBC provider out there besides the FM supplied one?

            • 3. Re: Interact with FP7 files programmatically
              Sorbsbuster

              I'm confused.  Can I confirm:

              - Your end of the pipeline is running FM Runtime files that are capable of generating exported data in FP7 format

              - The other end of the pipeline is running FP7 files (presumably as full FM Client?)

              - You want to send each other exported data, and for each other to import that data into your own files, for your own particular use?

              - You have no shared network (though when I think of it you could consider using Dropbox) but you could, for example, e-mail these files between each other?

              If that is the case, there shouldn't be any problem.  The exporting and importing of those files can be totally automatic.  (In fact, you can even have plug-ins that silently strip the attachment off an Outlook E-mail and save it to a known destination and then FM will silently pick it up when it opens.  But I don't think you need go there.)

              Can you clarify what part of 'The Process' they think is the obstacle?

              I'm also a tad confused by you saying "I can't figure out a way to do this without having an instance of FM  running": if no-one's running the files, what do you care about the data exchange?  And if someone comes along and opens the file, it can be made to import it / export it even automatically.  Would that be what you'd want?

              "There are a couple of people on my end that use an FM runtime  application that exports FP7 files to be sent to the other party.  Recently we've had a need to start capturing that data for our own  purposes".  So you have the data already?  So no export/import is necessary for you to go ahead and manipulate that data however you want?

              • 4. Re: Interact with FP7 files programmatically
                DevinGoble

                - Your end of the pipeline is running FM Runtime files that are capable of generating exported data in FP7 format

                Correct

                - The other end of the pipeline is running FP7 files (presumably as full FM Client?)

                Correct

                - You want to send each other exported data, and for each other to import that data into your own files, for your own particular use?

                I'm really only worried about exporting. We have no need to import data.

                - You have no shared network (though when I think of it you could consider using Dropbox) but you could, for example, e-mail these files between each other?

                Correct

                If that is the case, there shouldn't be any problem.  The exporting and importing of those files can be totally automatic.  (In fact, you can even have plug-ins that silently strip the attachment off an Outlook E-mail and save it to a known destination and then FM will silently pick it up when it opens.  But I don't think you need go there.)

                Correct

                Can you clarify what part of 'The Process' they think is the obstacle?

                They paid a lot of money for somebody to develop their solution. The developer's platform of choice was FM. However, considering what they are now expecting to be able to do, FM was the wrong choice. At this point they are telling me that the time and money involved in modifying the FM system that they use to accept CSV's is too much.

                I'm also a tad confused by you saying "I can't figure out a way to do this without having an instance of FM running": if no-one's running the files, what do you care about the data exchange?  And if someone comes along and opens the file, it can be made to import it / export it even automatically.  Would that be what you'd want?

                I have no need or desire to store my data in FM. In fact, for simplicity's sake, I'd prefer not to have it installed on any machines. However, I still have the requirement of being able to export FP7 files.

                "There are a couple of people on my end that use an FM runtime application that exports FP7 files to be sent to the other party. Recently we've had a need to start capturing that data for our own purposes".  So you have the data already?  So no export/import is necessary for you to go ahead and manipulate that data however you want?

                The problem is that the runtime application is terrible with no relief in sight. That's one of the reasons why we are developing our own solution (not in FM) to capture and manipulate this data. I guess what I'm looking for is some kind of component library that I can use from within our new system to work with FP7 files in order to automate the process of generating the export file.

                • 5. Re: Interact with FP7 files programmatically
                  Sorbsbuster

                  "considering what they are now expecting to be able to do, FM was the  wrong choice"

                  What falls into that category of "...now expecting FM to do"?

                  If what they want is simply for one location (your end) to occasionally export information held there to another location (their end) then I can't see what the problem is.  It's done every day, easy-peasy, lemon-squeezy, one-click or even no-click.

                  "the runtime application is terrible" - please clarify.  It may be the best or the worst of solutions known to humanity, but I can't see what connection the runtime bit has with a straightforward (sounding) data-exchange task.

                  "I have no need or desire to store my data in FM. In fact, for  simplicity's sake, I'd prefer not to have it installed on any machines.  However, I still have the requirement of being able to export FP7 files."  I thought the people at the 'other end' were running FP7?  So, at least somebody needs to be running it?  Why would you "prefer not to have it installed on any machines"?  Exchanging csv files is just as easy for FM - I only recommended that you exchange FP7 files because you can, and it is so easy.

                  "we are developing our own solution (not in FM) to capture and manipulate  this data" You are on an FM Forum, so I needn't apologise or explain that I am going to say "That's a shame, as FM is the database of choice for millions of us, and it seems to do a huge range of very complex tasks very competently from One-Man-Bands to Blue-Chip companies around the world, so it often makes us wary when people declare that some particular task 'seems to be beyond FM' "

                  I still can't see what their obstacle is yet.  Sorry.

                  • 6. Re: Interact with FP7 files programmatically
                    DevinGoble

                    "considering what they are now expecting to be able to do, FM was the wrong choice"

                    What falls into that category of "...now expecting FM to do"?

                    They are trying to use it to collect data from disparate locations, and the procedure is quite convoluted. Maybe not FM's fault, but it is what it is.

                    If what they want is simply for one location (your end) to occasionally export information held there to another location (their end) then I can't see what the problem is.  It's done every day, easy-peasy, lemon-squeezy, one-click or even no-click.

                    The problem is that I can't export data unless I use their runtime to make sure I can export an FP7 file. I can export dozens of other formats with not trouble at all, I just can't find the tools that I need to work with FP7 files.

                    "the runtime application is terrible" - please clarify.  It may be the best or the worst of solutions known to humanity, but I can't see what connection the runtime bit has with a straightforward (sounding) data-exchange task.

                    I meant terrible from the standpoint of having to use it every day to try and manage these records.

                    "I have no need or desire to store my data in FM. In fact, for simplicity's sake, I'd prefer not to have it installed on any machines. However, I still have the requirement of being able to export FP7 files."  I thought the people at the 'other end' were running FP7?  So, at least somebody needs to be running it?  Why would you "prefer not to have it installed on any machines"?  Exchanging csv files is just as easy for FM - I only recommended that you exchange FP7 files because you can, and it is so easy.

                    Yes, the other people are running FM. However, I don't want to. That's my preference, and the opinion of my team as well. We now are needing to have more control over the data that used to only be managed through the runtime application. Since we can't change the application, and need to have our data someplace that can be accessed by other people in different ways than the runtime application allows, we have decided to develop an in-house solution using other tools. We just don't have the time or resources to build out a FM infrastructure.

                    "we are developing our own solution (not in FM) to capture and manipulate this data" You are on an FM Forum, so I needn't apologise or explain that I am going to say "That's a shame, as FM is the database of choice for millions of us, and it seems to do a huge range of very complex tasks very competently from One-Man-Bands to Blue-Chip companies around the world, so it often makes us wary when people declare that some particular task 'seems to be beyond FM' "

                    No need to apologize or explain. I wouldn't expect you to. If lots of people find that FM works for them, then great. I'm not here to pick a fight. I'm only asking if there is a way to access an FP7 file through something like and ODBC driver that will let me talk to the file itself rather than needing to have FM running. I'm trying to build an automated process, and I can't have a desktop application involved. For file formats of all kinds I can obtain either first or third party components such as SDK's and libraries that will allow me access. Is this something that is within the capabilities of FM?

                    I still can't see what their obstacle is yet.  Sorry.

                    Their obstacle is that they are completely uninterested in modifying their solution to import anything other than FP7 files.

                    • 7. Re: Interact with FP7 files programmatically
                      Sorbsbuster

                      "Their obstacle is that they are completely uninterested in  modifying their solution to import anything other than FP7 files."  That's a shame: Filemaker will happily import and export to a wide range of file formats.

                      -

                      "They are trying to use it to collect data from disparate  locations"  How do they expect any other application to do that?  They can use Filemaker multi-user from inside and outside their LAN.  It can be accessed multi-user from the web, from Starbucks, from the home-worker's den, with a client or a web-browser; everyone accessing, viewing, editing, and updating the same database in real time.  Collating data doesn't come much easier than that.

                      --

                      "The problem is that I can't export data unless I use their  runtime to make sure I can export an FP7 file. I can export dozens of  other formats with not trouble at all, I just can't find the tools that I  need to work with FP7 files"  If you want to extract the raw data from an FP7 file you need to have the application running.  But you can set a schedule for the file to export its data to a timetable.  If you are truly exporting data from other applications then I'll guess you have to have them running, too.

                      --

                      "We just don't have the time or resources to build out a FM  infrastructure." Filemaker hasn't won its reputation as a Rapid Application Development tool for nothing.  Maybe you've got some sort of 'bad experience' going on here.

                      --

                      "Their obstacle is that they are completely uninterested in  modifying their solution to import anything other than FP7 files" 

                      That's a shame: I give up.