Server Side Importing

There's a great feeling about writing functional code when it's something you can rely on. You know it's just going to work. Which, for some import routines, doesn't always feel this way. Sometimes the import may fail or you can't figure out how to make it work.

Columns may get renamed, they may be shifted around and vary or you may be importing from multiple different providers. If you're consolidating data from multiple sources or you have a situation where you need to manipulate the data before the import, then we've got a great solution for you.

Not only is this video about server side importing, but it shows you how to anticipate a variety of situations that improve the importing performance and reliability.

The technique file and video will provide you with ready-to-copy-paste code that will setup your import routines to be as easy as drag-and-drop.

AttachmentSize
ServerSideImporting.zip1.68 MB
Tags:

Comments

Matt,

I've been wanting to implement something like this for one of my clients for a long time, but couldn't figure out how to go about it. This is going to greatly simplify the import scripting I currently do for this client. Thank you, as always, for sharing your outstanding ideas!

Mark

Matt thanks for a great video. One question I had was how do you deal with the n+1 version of import headings. For example you demonstrated control of two known header configurations. What happens when a third group sends you data that does not match the first two. Do you create some type of error and force either the importer to change the file headers or do you send error to developer to go in and the third scenario to your script. The latter seems overwhelming to maintain. Would it not be better to test import for standardized headers and reject if not in that format?

Richard belanger

You can always default to the developer "having to deal with it" - but we, as developers, don't like that. If I was creating a system where the variety of changes between import files would be really high, then I would create a table in the system that allowed the user to accommodate for varied headers.

I would just create a nice UI around "Import formats" and then allow the end user to specify the header criteria. You can always adapt your code to take user input and then wrap your functions around that. So, in this scenario, the data manipulation script would simply be expanded to use user supplied criteria. And, of course, I would create some defaults to get the user started with how things work.

Does that make sense/answer the question?

-- Matt Petrowsky - ISO FileMaker Magazine Editor

Thanks for the hint Matt. It is awesome. You think this works with the Get(Temporarypath) function on WebDirect too?
Thanks again,
Matt

Is it possible to convert this solution to use an xlsx file? Or any tips on how to automate between xlsx / csv within filemaker?

Thanks,

Anthony