In Subject “Read a Text file”, Joseph Mathew raised the question whether a dataport or a codeunit is the better way to import a text-file which requires some validation and treatment. Unfortunately Soren (Speedy-Gonzales) Nielsen closed the thread before I had a chance to reply: Joseph Mathew wrote:
quote:
I plan to use the following code to read a text file into a table […] The resons for not using the dataport are follows. 1. Since the files are from the different customers, I want to check the validity of file (All the informations in the files are ok for import) 2. It has to be decodes some values. 3. Import the values into more than one table including some calculated values. 4. Create a log files about this imports
Tim Horrigan wrote:
quote:
Actually, you (probably) should use a nonprinting report NOT a dataport and NOT a codeunit. Dataports should only be used to import beginning values during the initial installation and to transfer data from one Navision installation to another
Craig Bradney wrote:
quote:
As for using a dataport for this issue - its the only thing I would use and as I have said before in other postings using code behind dataports gives you all the functionality that Joseph wanted.
So what shall it be? a Dataport, a Codeunit or a non printing Report? Personally, I would second Joseph and make a Codeunit. I don’t see a reason for a report and I would definitely not make a Dataport! (Remember, data requires some validation and processing). Why? Well, unlike reports and dataports, codeunits are the only object where you see all the code in the C/SIDE editor. Using a Codeunit you need some additional coding lines to open the file and do the read-until-eof-processing but you have not only full control of what you do but you have it within visible range. In a dataport for on the other hand you have to press view → Dataport Fields → → F9 before you can reach the code executed for . Imagine it was another developer who programmed the dataport. You have to check each and every field for possible OnBeforeEvaluateField code. Therefore I recommend Dataports only for quick-and-dirty one-time jobs or very simple imports which do not require further manipulation of specific fields. I’m looking forward to get some arguments which stand against my point of view. Especially from Craig Bradney even though I know that Craig is currently on a business trip through Europe and will probably need some time until he’s able to answer. ------- With best regards from Switzerland Marcus Fabian
Originally posted by fabian: Why? Well, unlike reports and dataports, codeunits are the only object where you see all the code in the C/SIDE editor. Using a Codeunit you need some additional coding lines to open the file and do the read-until-eof-processing but you have not only full control of what you do but you have it within visible range. In a dataport for on the other hand you have to press view → Dataport Fields → → F9 before you can reach the code executed for . Imagine it was another developer who programmed the dataport. You have to check each and every field for possible OnBeforeEvaluateField code. Therefore I recommend Dataports only for quick-and-dirty one-time jobs or very simple imports which do not require further manipulation of specific fields. I’m looking forward to get some arguments which stand against my point of view. ------- With best regards from Switzerland Marcus Fabian
The nonprinting report’s looping features are handy. You can break out of the loop when you run out of data in the text file. I don’t like dataports for two reasons: 1. They have too many triggers to keep track of. 2. It is difficult to skip lines which have invalid data (e.g., header rows with text where numbers should go), and you have to have exactly one Navision record per line in the input file. 3. Non-programmers think they can write dataports Seriously, I had a boss who was very much NOT a trained Navision programmer who was CONVINCED that he should write dataports instead of me. He had no conception of how to use the (overly numerous) triggers in the dataport or even the table triggers— so he would build Excel spreadsheets which contained columns for each and every darned column with NO validation of ANY column. It took him HOURS to do a job which a programmer could do in one-20th the time, which was annoying (especially since he was also our only outside salesperson, and the time spent doing dataports was time he wasn’t spending selling the product so we could all make a few more dollars…) The big advantage of a report over a codeunit for this type of thing is that reports have automatic looping capabilities and they have just the right amount of triggers ------- Tim Horrigan horrigan@aol.com
I forgot to mention one more problem with DataPorts: you have to have exactly one Navision field per column of data in the input line. (Unless you do some pretty ugly finagling) you can NOT have “junk” data in the input lines. ------- Tim Horrigan horrigan@aol.com
I guess my arguments for doing data import with dataports is that they are built for that, you dont need to set up any file reading structures, or line based parsing code. If you can get the data into excel or access, or flat files then importing data is dead easy. Customers often export data from legacy systems into flat files and then manipulate them somewhat for formatting etc in excel. I make use of the AutoUpdate/Insert options when the data needs manipulation, ie, I turn them off, and then write the validation and manipulation code on afterimport trigger. This gives me the flexibility to do whatever i want with the data, validate it how i want and then insert or modify as required. Obviously you can then do reads and write to whatever table you want in the code. One thing to note is that you do not need to use the dataport’s primary table based variables in dataport fields, just dump any globals name in the dataport fields such as a another record.field, or just a normal global (integer or text). This makes v3 dataports even easier as the extra length text fields mean you can read very long lines of data, and wont need to use more than one global to import the data. This will just remove the need to write file operations for those that are writing codeunits. Another thing to note is that i rarely use the evaluate triggers, just the onafterimport trigger. I never have the Auto options turned on either, because there have been cases where I have seen tables becoming corrupted with them - a few validates are easy to write and you know exactly whats going on with all of the data. Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Email:cbradney@deloitte.com.au
Concur, Craig. Dataports can take up a lot of the dirty work of file imports (and exports) and by mixing real fields & dummy globals you can do any kind of processing you want after the record has been imported. The autoupdate and autoinsert properties can result in some unexpected effects and that has put some people I know off dataports altogether but I’m happy to use them. Cheers, John
Concur Craig, John. Turning off the autoupdate gives you as much control as a codeunit and without the hassle. I use codeunits for lots of things but, not to import data. Prior to becoming an end-user, I was a Senior Developer for a Solution Center for 5 years and I have never had to use a codeunit to import data. Also, if the text file is in fixed length format, you don’t even have to use dummy variables. I only use the before and after import triggers for the entire record, never the field level triggers. Bill Benefiel Manager of Information Systems Overhead Door Company billb@ohdindy.com (317) 842-7444 ext 117
Seriously, I had a boss who was very much NOT a trained Navision programmer who was CONVINCED that he should write dataports instead of me. He had no conception of how to use the (overly numerous) triggers in the dataport or even the table triggers— so he would build Excel spreadsheets which contained columns for each and every darned column with NO validation of ANY column. It took him HOURS to do a job which a programmer could do in one-20th the time, which was annoying (especially since he was also our only outside salesperson, and the time spent doing dataports was time he wasn’t spending selling the product so we could all make a few more dollars…) The big advantage of a report over a codeunit for this type of thing is that reports have automatic looping capabilities and they have just the right amount of triggers