Import - dataport or 'SQL-direct'

Is there any special reason why I should use a Navision dataport to import data, for example customer information. When looking at the SQL database tables it looks quite simple to do my own Inserts, right?

[Yes, you are completely right! Even though most of the developers will not agree with us. I also don’t like Dataports as they don’t provide the flexibility of Codeunits or (if talking about SQL) Stored Procedures. There is, however, one situation where dataports are the most convenient way to exchange data: If you want to make a quick-and dirty save of one specific table, you create a dataport in one minute and here you go. Or, if your customer improves his financial software package from something else to Navision and you have an export file with data from the old program which you once have to import into NF. Dataports are a good thing if you have to import large amount of structured data in one specific NF-table without converting/checking too much. — But only in this situation. Marcus Fabian phone: +41 79 4397872

In many cases it will be even simpler to insert directly through SQL! (see Marcus’ post for the reasons) We did quite some interfacing already with “foreign” systems using straight insertions into the SQL tables. As an example: a world-wide operating company is sending data from several Oracle systems, from a Peoplesoft system and from a SAP system to the SQL server where Navision is running on. Insertion is either into a joined “interface table”, or by having scheduled stored procedures reading directly from Oracle into Navision tables. Usually, it is “the other side” that’s rigid in the data format, but happily the combination of SQL and Navision is extremely flexible and can be configured to process about everything. Another example: the central webbased ordering system of one of the largest companies in the world is located near San Francisco, at the westcoast of the USA. The orderprocessing system (Navision) is located in Holland and the two networks were not allowed to have a direct connection for security reasons. So we developed for this company a solution using a JDBC-ODBC Bridge to do the transfer of data across the firewalls. The USA side runs a Java program that connects to a webserver in Holland, where it opens the Bridge and sends the data as SQL queries. With the upcoming use of XML as transfer format, dataports will reduce in importance even more. Webbased XML translators will grab the data out of the files and save it in the database directly. And it’s not needed to set up a heavy duty Microsoft webserver for this, there’s as much (if not more) software available on the Java platform - at a fraction of the costs. John

Thanks for the answers Marcus & John!