Difference between NODBC and C/FRONT

Please specify the difference between NODBC and C/FRONT in detail.

its advantages too…

NODBC is a database driver into the native database server. C/FRONT is kind of an API. They are both described in detail in the Application Designer Guide, which you can find on your product CD in the doc folder, it is called w1w1adg.pdf. If you are working with NAV 2009 then the ADG is integrated into the help system. You’ll need to get the latest help files to replace the ones that came on the product, because MSFT has modified them after RTM was released. I don’t have that link handy right now.

N/ODBC is the ODBC driver for the native Microsoft Dynamics NAV/Navision database.

C/Front is the SDK (software development kit) for Microsoft Dynamics NAV/Navision. Basically that means that it’s an API (application program interface) to develop third party applications integrated with Dynamics NAV. And it doesn’t matter if you connect to a native or a SQL Server based database.

The advantages of the NODBC is that it’s very easy to read data from the system into applications such as Microsoft Excel. But it’s IMHO not very good to update the application with. Especially since you cannot access the business logic in NAV, only the tables and records.

C/Front is a nice tool which allows you to both read and write in a more controlled mannor than NODBC, although you still cannot access the businss logic, only tables and records. But you need to use a programming language to embed the API into your program, such as VB or C++. You CAN use it from Excel, but it requires that you write a rather complex macro using VB.

Hi Erik,

Since we cannot access the business logic of NAV in both ways, which approach do you recommend in terms of reliability,performance and ease of use?

Thank you in advance for your cooperation.

Regards,
HH

Houssam,

It really depends on what you need.

In general I would never recommend to use ODBC if you need it in-corporated into 3rd party system. Here I would prefer C/FRONT. But let’s know what you need.

Thank you for ur prompt reply.

Shortly, we are looking to Exchange data (Read & Write) between our retail self developed “dotnet application” and MS. Dynamics Navision 2009.

I would consider Web Services here. That will get you access to the NAV business logic and since your application is “self developed” you would have the flexibility to adapt it.

Web services would use NODBC or CFrontDotnet to connect with Navision thus unable to access Navision BL.

What i need to know is which approach is most recommended for my case?

In case am going to proceed with NODBC, what are the problems i may face which are solved with the CFrontDotnet API?

Thank you and Best Regards,
HH

One of the options is Navision Application Server. With NAS you can initiate NAV business logic. NAS is very stable approach for many kinds of integration. With NAS you can create sync or async integration model. 1 instance of NAS comes with NAV licence.

In case you proceed with NODBC you have to know that you cannot use SQL Server Option for Dynamics NAV (unlike cfront).

Thank you for introducing NAS since i was not aware it exists - I am new to Navision. Now, i would perform some extensive research about-it to know the in & out.

However, it seems am not going to face problems on CRUD operations through NODBC therefore will proceed with it taking into consideration the drawback of not being able to use SQL Server Option for Dynamics Nav that im not aware of what it is used for. Also, we have to consider the learning curve of CFrontDotnet API which does not exist when using NODBC.

Thank you all.

Cheers,
HH

You can use ODBC with the SQL Server Option. Just not NODBC. NODBC is the ODBC driver for the native database. With the SQL Server Option you would use the SQL ODBC driver or the Native SQL driver. Either way though you need to be careful when updating the database from outside as the business logic is not executed. This is not a recommended approach.

Hello Babrown,

When Updating the DataBase, could you please elaborate “the business logic not executed” point? Does CFront API execute the BL?

What is the difference between using ODBC objects (odbcConnection, odbcDataAdapter, odbcCommand,…) and using Microsoft.Dynamics.Nav.CFront.CFrontDotNet.dll objects? Am i going to face problems when executing complex queries? Peformance bottlenecks? Integration issues ?

Thank you for your highly appreciated help.

Best Regards,
HH

Neither of these options (NODBC or C/Front) execute the business logic (c/side code). This code is not only the business applciation logic but also maintains the relationships between tables. For example, if you delete a sales header record, there is code that also deletes the associated sales lines and other records. If you delete a sales header, with NODBC or C/Front, you would need to handle these other deletes in your code or end up with orphaned records.

Unless you have a very deep understaning of the NAV application, (and a desire to duplicate the behavior) you should limit NODBC or C/Front access to read-only queries or updating of “staging” tables only. Even with a deep understanding I would not recommend this approach.

1 - So, There are no difference between NODBC and CFront for CRUD operations?

2 - If neither of NODBC or CFRONT are recommended, are we talking about Navision Application Server (NAS) or what?

Thank you again Babrown.

Regards,
HH

As far as the “they don’t execute the NAV code” disccusion, they are the same. But there are differences in how you integrate them (see Erik’s post above)

Yes, NAS would be one availabe option. Also NAV Webservices, but this would mean moving to NAV SQL Option and client upgrade (depending on what version you are now on)

That is one of the more interesting suggestions…however…it still seems off target from Robin’s original post. If somebody send you an “FBK” backup of their Navision system…presumeably chock full of tables with various fields and other objects… and you don’t have connectivity to their Navision system…all you have is the “backup”…and you don’t have a Navision system to “restore” anything from the backup…you seem to be SOL. What we need…is a way to yank the tables and fields out of the backup…kicking and screaming into something that she CAN work with…like…a SQL database…or… MS Access or something. Now an FBK file may well be a “propriety format”… so are earlier MS Excel documents. Now one way to get the data out of Excel…is to “EXPORT” tha data in a delimited format…using Excel… but “If you don’t have Excel” I bet you can import the data into…“open office” or “something else” that can read the proprietary format. So… does anybody know how to forcibly drag raw tables out of an FBK into some…“other format” (delimited?) …without any access to a Navison Server whatsoever. That…is the question.