maiobusy.blogg.se

Once you have your query perfected in RazorSQL, you can then build it in FileMaker, knowing that you have the basic query correct. With regard to the last issue, RazorSQL is a nice tool for working directly with your FileMaker solution to very quickly test SQL code. On the down side, you have to be very careful about its impact on your application’s performance and building SQL queries in FileMaker’s calculation dialog is challenging. It can help keep your relationship graph simpler, allow you to query data without changing your context, and makes virtual lists easier to build among other things. The advantages and disadvantages of SQL in FileMaker are pretty well known.

In the early days it required a 3rd party plugin, but since version 12 we’ve been able to run SQL Select statements against our FileMaker data with the native Execute SQL function. Regardless of whether you are loading in series or in parallel, you should have checks on each command exit-code, and an ability to restart from the point of failure, and to verify that the number of rows loaded matches the number of rows in each IXF file (accounting for any rejected rows).Developer’s have been able to run SQL queries against their FileMaker data for many years. There is no benefit to this approach unless your containers are on a SAN with plenty of I/O bandwidth. For example if you have 32 cores, you might have 20 concurrent load jobs each loading a separate table with subtask having its own connection to the database. More sophisticated ways include using the Db2 LOAD utility in parallel, depending on the number of cores you have available, and the avaialable I/O bandwidth. Simplest (and slowest) way is to use the Db2 LOAD utility to inject the files in series. You can also script this type of stuff in perl, or python, or any scripting language. You will need to know which file populates which table regardless of the technique you use.ĭb2 on Linux is very programmable with shell scripting (for example, with bash).

The solution depends on your scripting skills, and how often you want to run the job. Only use import if you already know the files are tiny and there is sufficient transaction logging capacity, or the tables exist but not the indexes and you want the import action to create the indexes also. For speed reasons, you don't have to use import, you can instead use the Db2 load utility.