using n/odbc good idea?

alpinefd · 2011-11-19

Hi Guys,

We are trying to find a way to send pdf from Navision with the following functionalities

1. batch send (invoice / packing list) to order contact's email address
2. individual send by one click to order contact's email address
3. merge certain fields from the order into email body and subject (ex. Dear "Contact First Name", your order # "SO#")
4. does not use up more than 1-2 table objects.

seems like an easy enough requirement, but i'm having a hard time finding a ready made solution fitting the above criteria.

so finally I found docufire (www.docufire.com), a solution for batch pdf/fax from erp system. It checks all the boxes above, but so far they've only developed a Nav SQL connector.

Basically docufire install as a print driver on the client machine, when the client prints a NAV report to docufire, it queries the NAV database and gets all the required merge fields based on customer or contact id on the report.

The developer is proposing to develop a plug in for Native DB using N/ODBC.

My question are as follows:

1, is this a good / bad idea? Any potential pitfalls using N/ODBC?

2. It seems used in this manner, everytime the user send pdf via docufire, it will send an ODBC query to Nav DB. There could be quite alot of ODBC queries throught the day. Will this cause any performance or reliability issue with Nav DB?

3. Also does NAV DB has any concurrency limit on ODBC connections?

Any advice will be greatly appreciated.

Thank you !

Randy

kine · 2011-11-19

Question is, is it worth it to develop something like that, when you know that Native DB is dead? Isn't it better to think about upgrade to MS SQL?

David_Singleton · 2011-11-19

Kamil just posted my exact thoughts.

alpinefd · 2011-11-20

Hi Guys,

We are fairly small company with simple IT capability, and likes the maintenance free native db

No plans to move to SQL in the near future.

It would be fairly simple for the developer to implement the N/ODBC, they already tested the connector using visual studio and is comfortable doing it, the only issue is each client have to have N/ODBC service installed, and I was just wondering if that's a good idea or not. And also if each odbc connection use up any concurrency license in the nav DB.

Thank you !

Randy

kine · 2011-11-20

Even if the N/ODBC is not taking the license, you will need to buy Light User for each named user accessing the NAV DB from outside NAV client...

Mike_HWG · 2011-11-21

You may be interested in looking at Altus Mail/Fax?

Additionally, I worked with a company in the past where we would integrate NAV with a PDF writing software called PDF995. Unfortunately I wasn't on the dev team at the time so I'm not familiar with what was done code-wise, but I believe you can call the software directly from NAV to make it generate the result... note that the email part would be a separate hurdle.

Savatage · 2011-11-21

alpinefd wrote:

And also if each odbc connection use up any concurrency license in the nav DB.

We use it for our Cyrstal Reports to connect to the database.
It does take up a license for everyone the runs a report.

so say we have 10 users - 5 logged in & 5 running reports - then were out of open users!
It's unusual for everybody to be running reports all day at the same time.
So free sessions open up quickly.
we also use autocloseidle - to kill opened & unused sessions.

plus I can always close my client to run the report & then when the report is over - switch back.

Mike_HWG · 2011-11-21

If there's a concurrency issue with licensing, couldn't you get fancy with Job Queueing to create a scheduled report run? this is, of course, if you have a supported version of NAV and the report parameters tend to be uniform...

using n/odbc good idea?

Comments

Categories