To NAS or to VIEW / SQL

trinsan

CASE A:

Considering a case wherein you want a webpage to lookup a specific set of statistics (say how many of all vendor types are there) would you use NAS or settle with a SQL-server VIEW?

To me, a NAS is really only interesting when needing to edit data directly in NAV. E.g. letting the vendor alter his/her type through a webpage.

When looking up data, it seems a tedious process to use NAS. :?

CASE B:

Consider a case wherin you want vendors to sign up for a newsletter. Vendors enter their vendor number and an email adresse.

Would you use a NAS solution, or would you register signups in a temporary table, and import the informaiton later using a code unit?

I'm considering the safety aspects of the solution. NAS would - depending on the design - edit the data directly in the vendor table, whereas using a simpler solution, importing the changes through a codeunit accessible on a form,.

----

Or am I mistaken?

Whats you call. In the examples above I have little use for NAV business logic, as you would otherwise do in the handling of sales and units available in a warehouse. So NAS seems a bit overkill?

Furthermore my concernes regarding NAS relate to future Navision editions. Should I choose to develop a lot of small web-widgets depending on NAS, I'm pretty certain I'd have to redo most of it in the near future, as NAV certainly seems to integrate stronger with SQL-server by each edition.

I'd appreciate your views and oppinions..

Cheers, Trin

jlandeen

From a technical perspective I always consider the back end SQL tables read only from the perspective of other systems. As long as you are only reading data from the table directly there is no need to have a NAS in place and you can remove a layer out of your architecture which can keep maintenance simple and possibly have a performance benefits. Note that (as discussed in other threads here) there may be licensing issues depending on the model you are licensed under...especially if you are requried to purchase DCO licenses for named user access.

This process becomes more complicated if you have to do any writes back to Navision. I would never ever suggest other systems write directly to NAV controlled tables, and you will require something to kick off any Navision processing logic. This could be a form/report that is invoked by a user on a regular basis (say daily) or handled in a more automated fashion with a NAS. In those cases it would work quite well if you had a staging table for your external system to write records into that are processed later by Navision. Note this process works well with 5.0 SP1 and previous versions of Navision. If you are running in NAV 2009 you could use a web service based approach and have your external system send web requests to NAV.

So in summary...if you only need to read data from Navision just go to the tables if you need to write any data you should use NAS (to ensure that all Navision business and validation logic is processed properly).

i4tost

when you write directly to NAV database do not forget about licence. It is unlegal if you do not have appropriate granule within license (i do not remember which).
I always use NAS and do not have any problem. Also I know, that I (not end user) can change anything I want without any problem and easily give this to my customer.

trinsan

Technically neither practical case write directly to NAV tables. From a basic bookie's perspective that would render NAV entirely useless. I'd never do that.

Without NAS, I would read form the NAV tables, or let NAV read from external tables. Therein lies the difference.

Essentially (pardon the schematic)

Reading:
External program <---- SQL view <---- NAV

Writing
External program ----> temp tablex ----> NAV (fetch from temp tables via codeunit)

Should save me the headache of using NAS, and since the data is always to manually processed for errors before writing it to the vendor tables.

Cheers, Trin

jlandeen

On the writing side of your solution remember you don't necessarily have to use a codeunit to access data stored in external tables. You can build a NAV table that is based on a SQL view instead. Then you can access the records as usual from NAV code.

trinsan

Yeah, I just read about linked objects yesterday, and that certainly simplifies some matters siginiicantly.