ODBC?

I just read in technical information reference guide of Navision (thx to Nelson Alberto) that the system supports OBDC. That means that I can use query in my code to display Data? If so, may someone show me an exmaple or a link that shows it? thx

I assume you mean ODBC. Yes, it is supported. Tho there are many limitations and flaws in their driver. Use Crystal or some other product to write and monitor your sql statements, formulas, queries, etc.

Hi, it’s me again! [:D] Thanks for the mention [:)] True, Navision supports ODBC access to the native database. You need to install the ODBC driver with the same version as the database server you want to connect to. Then it is basically the same as any other ODBC Data Source, configured through Windows Control Panel. This allows you to access the native Navision database from outside and run queries on the data. But, from your message, I’m led to believe that you thought this could be performed inside Navision (in C/AL code). I’m sorry to say that is not the case.

By the way, there will be a new ODBC driver in Navision 4.0…

Will it be possible to perform ODBC operations inside navision 4.0? If so, what advantages will get using Navision instead of Visual Basic + Crystal report? Wich leads me to an important question. It’s been about 3 week that I am developping on Navision, and I was asking myself, what are the big advantages of using this product compare to everything else?

No, it will never be possible to do ODBC operations inside Navision. Not what ODBC was designed for. Crystal is a nice reporting tool, but Navision has never had a very good ODBC driver, will be surprised if version 4 is much different. Basically worthless compared to an Oracle, Informix or SQL Server ODBC driver.

In a preview presentation of 4.0 we were told there will be a new ODBC driver. Monday we will probably get more details…

btw, funny thing you say about SQL odbc… isn’t it possible to run navision on SQL? [:D] A couple of months ago, our company decided, with the integration of navision and SQL becoming better and better, when a new customer wants to implement navision, to run it on SQL…

Ha ha, ver funny Peter. After following the misadventures of Navision/SQL users on the forums here, you must be joking? No way would I try to run navision on a SQL server at this point in time. You very funny man. :wink:

Huh? - we have lots of (big) SQL installations running problemfree - don’t trust everything you read.

Thats’s just it - nobody will spontaneously post something here saying ‘Hey, we’re running SQL and everything is fine - just thought I’d share it’. But you will of course here of all the problems because that is when people need help. Just read my own post and it seems rather like stating the obvious!

SV, spoken like a true consultant. Your statement on problem free installs is pure BS, and you know it.

I don’t think SV is saying problem free installs, I think SV is saying the installations are running without problems. He doesn’t mention how much time and effort was involved in making the installations run without problems.

John, I don’t much care for the tone of your last posting. Heavy words are easily thrown. Implicitly you are questioning not only my word but also the integrity of consultants in general. At least my statement was build on facts and years of personal experience whereas yours, it seems, is build on religious prejustice and heresay. Mind you, I’m not knocking the native db at all, I’m a great fan. In many (most) cases it’s the best choice. Very stable, extremely quick and compared to SQL both HW- and maintenance-wise a lot simpler (and cheaper) than an SQL-installation. I some cases, though, SQL is the best (or only) choice, primarily when:

  • The no. of users is high
  • The Amount of data is overwhelming
  • The need for an open environment is imperative
    It’s your job , as a consultant, to offer unbiased (i.e. not religious) and qualified guidance to the customer in each case. All i’m saying is, that if it turns out - after deliberate analysis - that an SQL-installation is the better/logical choice and this choice is backed up with the adequate amount of competence, know-how and professionalism, I see no reason why - at the end of the day - it shouldn’t be a success.

Besides that, the integration with SQL has become better. We did some performance tests for a customer in the sales process, where around 600.000 invoices had to be posted within a weekend. Try to do that on native, along with a 120 conc. user implementation! Tests indicated that SQL was multiple factors faster. However, implementing SQL requires much more knowledge from you MBS partner. Most partners don’t have SQL knowledge and think this is just an alternative option besides native. Knowing SQL well will give you much more advantages than you think. I also want to join Steven Voels opinion, we have several SQL customers, who are very much sattisfied, where did a problem free implementation. It just stands or falls with knowledge… John T: it’s true SV says, the problem with IT management is that you don’t build up credit, you only lose it. When it works, it is supposed to. When it doesn’t work, that’s bad. I can assure you that more and more new customers will turn to SQL, not just ours. The integration will improve, and within 2 years more SQL than native will be sold. Remind me in jan. 2006 of this statement… And besides that, you can only talk about when having expierenced it, not after only having read about it…

Maybe what you say is true, but we wanted to move to SQL and were heavily advised against it by our consulting group and research on this forum supported their claims. I am not worried about building up credit or making you people feel better, this is a business we run here. If you can’t take the heat get out of the kitchen. Your comment about talking about something after experiencing it is ignorant. We don’t need to go down all roads to determine which are dead-ends.

Thx for the info guys, I am so curious what this new upgrade will do. So what some of you guys are saying is that maybe the new ODBC driver in Navision will turn to be more SQL Native… But is that what Navision is supposed to be? The way I see this program right now is more like of a user friendly approach. The thing goes well when easy stuff must be done. But when your report (or anything else) goes complicated, all automation of Navision is lost and it becomes hard to perform a task that should be easy in SQL native. So it must be why the program must turn to SQL to survive… What do you think?

Thx for the info guys, I am so curious what this new upgrade will do. So what some of you guys are saying is that maybe the new ODBC driver in Navision will turn to be more SQL Native… But is that what Navision is supposed to be? The way I see this program right now is more like of a user friendly approach. The thing goes well when easy stuff must be done. But when your report (or anything else) goes complicated, all automation of Navision is lost and it becomes hard to perform a task that should be easy in SQL native. So it must be why the program must turn to SQL to survive… What do you think?

Yes, here is one request that I am trying to figure out…

I have been asked to create a report of orders that have been released, but have not yet shipped.

I do not have access to any of the NAV screens. I only have access to the NAV database via ODBC (read only).

I have looked at the fields in the “Sales Header” table but I am not sure if this table contains the data that I need. For example, is there a field in the “Sales Header” table that indicates if an order has been shipped or not. There is a status field, but I am not sure what this is used for.

Thanks for your assistance.

Brad

There are three fields you need
Document Type (Field 1): It looks like you want type “Order”
Options(Quote,Order,Invoice,Credit Memo,Blanket Order,Return Order)

Status (Field 120) : It looks like you want “Released”
Options (Open,Released)

Completely Shipped (Field 5752) : Boolean If it’s completely Shipped The it = True else False