The script starts from Layout number 1, and proceeds layout by layout. In the tip files I simulated a situation in which you have a central location (wrap.fmp12) that will send updates to a remote location (unwrap.fmp12) two tables will be updated, Products… Let’s see the technique in detail, using the tip files accompanying the article. Warning for those worried about XML: don’t worry, it’s elementary XML. The block of text can be sent to the remote location, where it will be unwrapped, thus recreating the original records. The data are wrapped into an XML shell, encapsulating each data element (table, record, field) into appropriate XML tags. I therefore developed a technique, that I dubbed wrap & unwrap it basically creates a single block of text containing the update data. Remember, I needed something rather simple to run, with the possibility of choosing single tables, and “atomic” enough to avoid any problem about data integrity. The interesting part is however how to update the Codes and the Controls table. By doing this I’m able to update codes and logic updating the relevant tables. I ended up moving all the logic into a Controls table, and a script using plenty of GetField() and Evaluate() performs the controls. Hmmm, there must be a better way to have an updateable solution. And how about the customers for whom I integrated the file into their solutions? What will it happen to my customers when new releases get out? Will I send them a new version and a large old-data-import routine with it? Doable, already been there, but didn’t like it at all. The tricky part however is right behind the corner: codes and conditions will change in future releases. So far things look easy to accomplish using value lists and field validations. You need to check that all mandatory fields have been filled, that field format and length falls within given limits, and that some fields have a value if some conditions are met. I developed a solution to send electronic invoices to the State Administration (for those who are maniac enough and fluent in Italian, details here: ).īriefly you need to create an XML file containing the invoice data many fields use codes provided by the administration. It is becoming increasingly necessary to move easily and reliably data from one file to another, and I’ve been recently faced with a similar problem. Here he presents a technique to move data between disconnected FileMaker systems. Editor’s Note: today we have a guest article with demo files by Italian developer Giuseppe Pupita, whose helpful and knowledgeable postings in various online forums are always worth reading.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |