4 Replies Latest reply on Aug 22, 2012 8:35 AM by philmodjunk

    Exporting records to remote database



      Exporting records to remote database


      Hello, we currently have a standalone register file run on several computers that connect to a database file on our server. In an effort to reduce errors we are not going to use a live update and instead the register will store all of its info locally until the register is closed out, then it will upload to the database as a batch update, and then the local info is erased. I could probably script adding all of this info through a series of loops and dozens of variables, but I was wondering if the batch update could done using filemaker's built-in Importing/Exporting of records.

        • 1. Re: Exporting records to remote database

          I am unclear.

          Cash registers (3?) running on Windows (ver??)? Running Filemaker or something else for the register?

          All registers exports daily to the folder containing the Filemaker (ver ??) - exports what kind of file - Comma deliminated, TAB deliminated?

          • 2. Re: Exporting records to remote database

            In an effort to reduce errors

            What "errors' are you attempting to reduce with this added complication?

            With the right external data source references and Import Records, it's possible to pull the data from local files into a table in a hosted copy of FileMaker Pro, but I wouldn't do that without a very good reason and I'm having trouble imagining what 'errors' might be prevented or reduced by such an approach.

            • 3. Re: Exporting records to remote database

              Cash registers (3?) running on Windows (ver??)? Running Filemaker or something else for the register?

              Anywhere from two to five registers are running, depending on the day. We are actually using G4 "Snowball" iMacs. The database and register are both Filemaker files, the database being hosted on Filemaker Server.

              What "errors' are you attempting to reduce with this added complication?

              The errors have occured multiple thimes which is why we are trying to change it. Frequent crashes leading to information not correctly sent to the database. I suggested this since it reduces the total amount of record updates sent to the database and so it would also reduce the chances of these transfer errors, for example: with our current "live updates" system if someone sells an item it will mark it as sold in our inventory tracking, but if that sale is voided afterwards it has to update the inventory again. With the batch update it would only update the inventory once (voids occur often enough that this would reduce updates by quite a lot). Also simply importing the records into the database would reduce the chancces of scripting errors affecting the database. Having a single point of database updates also would be easier for debugging.

              Anyways, I think have figured out a method. I realized you can call scripts in linked files so I would make a script in the database to import records and then call it from the register file. I can see a pontential problem of getting a valid filepath remotely. I haven't had time yet to test anything though.

              • 4. Re: Exporting records to remote database

                We have 5 different stations entering data into a Filemaker Server hosted database with 3 more stations printing out receipts of the data entered from the other 5. It's rock solid. No errors and very, very few crashes. It's a scrap and used beverage recycling operation with a postage stamp sized parking lot. We have to move customers through very rapidly with out errors on our receipts and FileMaker is up to the task.

                It sounds like your systems are not correctly accessing your hosted database--which can damage yoru file or the file itself may be damaged. Either that, or your network has problems that need to be resolved. I don't think your plans for keeping the data local and doing a batch update are likely to solve such issues. They may make them less likely but all you need is for this to happen once in a month's time for there to be real problems with your data.

                Your file should be hosted over a local area network from a computer that has a) the database file and b) a copy of either FileMaker Pro or FileMaker Server. I recommend server given it's enhanced capabilities even though you don't have enough users to require it, but FileMaker Pro should be up to the task. You then open the files with either Pro or Server on this machine and each of your client machines use Open Remote to find and open the hosted file or files.

                Some users try to put the file on a shared directory and open it directly using Open from the File Menu or a functional equivalent. This is a dangerous way to share FileMaker as it can result in a damaged database file. If you have been using this method, you should run a recover on your file to check it for damage.

                Things to keep in mind about Recover:

                While Recover almost always detects and fully corrects any problems with your file...

                1. The recovered copy may behave differently even if recover reports "no problems found".
                2. Recover does not detect all problems
                3. Recover doesn't always fix all problems correctly
                4. Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.