New Database

aliennav

Hi Everyone
I am going to create a new database.I want to ask that the only way to mass upload the data is through dataport?

Savatage

is this a new installation?
where is your data now..excel, txt file, csv file, etc?

or is it a different nav database already?

diptish.naskar

Depends where the currect data is.. your previous NAV datavase,excel,txt?

aliennav

We r starting a new project and most of the database is in excel or csv format

Waldo

YOu can use the mapping objects in NAV as well, but usually it's done by dataports, indeed... .

diptish.naskar

If it is a NAV database then go ahead with dataports and if you are planning to go ahead with SQL server option then you can try it with SSIS.

aliennav

Thanks For your reply

Waldo

diptish.naskar wrote:

If it is a NAV database then go ahead with dataports and if you are planning to go ahead with SQL server option then you can try it with SSIS.

Uploading data throug SSIS ??
I would never do that! What about field validation?

diptish.naskar

Yeaps....not to stress on the field validation it will not happen in the SSIS which can be done through dataports.

David_Singleton

Waldo wrote:

diptish.naskar wrote:

If it is a NAV database then go ahead with dataports and if you are planning to go ahead with SQL server option then you can try it with SSIS.

Uploading data throug SSIS ??
I would never do that! What about field validation?

Actually I did one Navision go-live (on C/SIDE DB), where Dataports were so slow, that we would not have a chance to complete the conversion during a weekend, and there was so much data, that codeunits would just have been too much work, so in the end we did the conversion using DTS onto SQL, then backed up the SQL db,and restored it to the actual Native database.

The ratio of Dataport to DTS speed was many orders of magnitude. i.e. hours vs seconds.

Oh and another great thing, is that after go-live the client had all the data from their old system in Navision, so the reconciliation was very easy.

Waldo

I can hardly imagine no field validation was required... .
How did you handle that?

diptish.naskar

David Wrote:

Actually I did one Navision go-live (on C/SIDE DB), where Dataports were so slow, that we would not have a chance to complete the conversion during a weekend, and there was so much data, that codeunits would just have been too much work, so in the end we did the conversion using DTS onto SQL, then backed up the SQL db,and restored it to the actual Native database.

The ratio of Dataport to DTS speed was many orders of magnitude. i.e. hours vs seconds.

Oh and another great thing, is that after go-live the client had all the data from their old system in Navision, so the reconciliation was very easy.

Thanks David,
=D> =D>
I thought SSIS is definitely one of the solution, but I had never done it myself, but its really nice to hear that you have done something like that.

DenSter

diptish.naskar wrote:

David Wrote:

Actually I did one Navision go-live (on C/SIDE DB), where Dataports were so slow, that we would not have a chance to complete the conversion during a weekend, and there was so much data, that codeunits would just have been too much work, so in the end we did the conversion using DTS onto SQL, then backed up the SQL db,and restored it to the actual Native database.

The ratio of Dataport to DTS speed was many orders of magnitude. i.e. hours vs seconds.

Oh and another great thing, is that after go-live the client had all the data from their old system in Navision, so the reconciliation was very easy.

Thanks David,
=D> =D>
I thought SSIS is definitely one of the solution, but I had never done it myself, but its really nice to hear that you have done something like that.

Yeah well there is one great big HUGE difference. David actually knows what to look for and make sure all the necessary data is there, so he has the experience and skills to do this without f%$#ing up the database, and even then he knows that doing it that way is taking huge risks, and he then spends a long time verifying the data, again knowing what to look for.

Don't use DTS, or SSIS, unless it is impossible to use regular NAV tools. Do NOT make it your tool of choice. You WILL get into enormous problems.

Waldo

OK, thanks , I seriously started doubting myself ... 8-[ .

I really would like to hear David's comments on how he handled the validation.

David_Singleton

Waldo wrote:

OK, thanks , I seriously started doubting myself ... 8-[ .

I really would like to hear David's comments on how he handled the validation.

OK, there may be some misunderstanding here. The issue was "how to get the data into Navision" from a technical point of view, which is what I was answering. specifically tho point that I would generally prefer DTS (or ssis as they now call it), over dataports. So just to clarify.

Yes as Daniel says, this was a huge job. mainly because of the size of the data, and the tight conversion window that we had. And dataports killed us from both sides. A the legacy system was very slow at creating text files, and also would sometimes crash, so we had to export a file, check it then if its ok send it to the Navision dataport.. But there was a tool that mapped the data structure to a normal DTS, and thus with SQL we were able to just move data across. The original plan was to use the Navision LinkedObjects, and just access a pseudo SQL database from in Navision. But after about 2 or 3 million records, LinkedObjects are ridiculously slow. so instead the client just purchased about 50 or so new tables, and we just created those as exact copies of the key tables in the existing Legacy database. The DTS just moved the data from the legacy system to Navision.

We had a number of routines for data population. Tables like customers and items were updated once per week if they changed, and the week before go-live we moved across all posted data, transfered it to journals (using a simple non printing report). and posted them. So once go live came ready, all we needed to do was post the transactions for that week and then get the open orders all matched up. Which we did by simply creating orders for the remaining quantities and GL invoices for goods already shipped/received.

Anyway, I think the key here, is that we could not have done this without DTX, BUT all the validation was done in Navision using normal Navision routines. DTS was used ONLY to populate the new tables that we created. What was interesting, was that because of the way we did this, users were actually able to start working in the live Navision system, BEFORE we had finished the posting of all the journals. This is because we took one transaction at a time from the SQL tables, created a journal and posted it then committed.

The auditing of the system was a dream, because we had all the data from the Legacy system in Navision , it was very easy to prove to the auditors.

In fact the client wanted us to just populate the Entry tables directly, which I refused to do.

So definitely Daniel and Eric are 100% correct in their comments. And if anyone thought I was populating Navision entry tables directly form the outside, then sorry for the confusion.

DenSter

Thanks David for the clarification. That demonstrates exactly what I meant. So the data was moved into staging tables, and then a NAV process moved them into journals that were then posted by NAV.

So to qualify my comments: don't make this your tool of choice unless you know what you're doing on the NAV business logical side.