Using .NET instead ADO ??

gjgarciasm

Hi,

I have used many times ADO - Automation Microsoft ActiveX Data Objects - from Navision code to access to different kinds of databases like Oracle, SQL Server. In fact it is a good strategy to create connectors using transactions to controll data insertions, updates and deletes.

Mi question is that I am new in .NET technology and I am very interested in answering the following:

I have to develop a new conector with several Microsoft Applications. Is there any kind of similar way or procedure to work using .NET automation objects or similar technology instead ADO objects? Any reference will be helpful. :?

I am sorry if the question is a nonsense but I am very new in .NET.

Thank you very much.

jesam

Do you mean to use .NET objects/components from Navison (or any other host) or from a standalone .NET application ?
And .NET 1.1 or .NET 2.0 ?

gjgarciasm

jesam wrote:

Do you mean to use .NET objects/components from Navison (or any other host) or from a standalone .NET application ?
And .NET 1.1 or .NET 2.0 ?

Hi,

I think the place is not important because for example you can use ADO from a Navision client, old ASP pages, Visual Basic Applications, C++ Applications, etc.

But I need implement this kind of functionality from Navision clients specifically.

Thank you.

jesam

Well, the place is important.
Navision (and ASP classic and VBA and lots of other hosts) only talks COM, not .NET, so you cannot use the .NET SQL libraries directly from Navision. You could write your own wrapper around them and make that wrapper COM visible, but that would only add a layer upon a layer and have the side effect that to use that component you would not only have to make sure that MDAC but also the NET framework is installed on any computer you would want to use it. Even worse, when you try to go to the DB, not only would the MDAC component have to be fired up, but also the .NET framework.
The only good reason to ise .NET to connect to SQL is when the software that needs that connection can talk .NET to that connection instead of having to go through COM interop.

So if you need a SQL connection from Navision clients, just use plain old ADO, there really is no point in using .NET SQLAdapters and DataSets.

TikusJalang

hmm.. data access with ADO and .NET technology is different, because .NET uses dataset, and connection to datasource is disconnect if dataset has filled...
I've explore and search for automation that support .NET database component like datareader,datadapter,etc... but until now I can't find that component....

but I heard that CFRONT in NAV4.0 SP1 has changed into CFRONT.NET, I think it can talk to another window app and web app that is develop under .NET tech....
CMIIW....

jesam

hmm.. data access with ADO and .NET technology is different, because .NET uses dataset, and connection to datasource is disconnect if dataset has filled...

It is true that the idea of a connected recordset no longer exists in .NET 1.1 (I'm not sure if they brought it back in .NET 2.0, but we're not using that version yet, and even if we were we wouldn't use connected recordsets), but you could always use a datareader instead, which is like a connected recordset that you can only read sequaetally (we don't use that either).

I've explore and search for automation that support .NET database component like datareader,datadapter,etc... but until now I can't find that component....

It would be like going from Moscow to Bejing over Paris, there really is no point in doing that, ADO works perfectly if you want to access SQL from a COM host.

but I heard that CFRONT in NAV4.0 SP1 has changed into CFRONT.NET, I think it can talk to another window app and web app that is develop under .NET tech....

All I heard about that makes me think that it is a .NET wrapper that makes (parts of) Navision visible in a .NET environment. If it were the other way it would mean they would have to host the CLR in Navision and I doubt they would release that as a service pack. Given the amount of time it took them to pull this of with SQL Server 2005 I doubt if they will have that ready for Navision 5.0, if they even consider it ...

DenSter

They gave us a .NET version of the C/FRONT dll, so you can use C/FRONT in the .NET framework. I doubt it is useful to call C/FRONT from within Navision. You really wouldn't have any use for it, since you're already IN Navision .

It's been said before... Navision doesn't know how to talk directly to .NET, it has to be COM compatible. If you have working code, why change it? Just so you can say you are .NET compatible?

gjgarciasm

Hi,

I conclude of your interesting information that programming C/AL code to connect to external datasources through .NET technology may be posibble but it is only worthy if you are obliged to do it. For example, If you have other .NET application and you have to access it.

DenSter wrote:

If you have working code, why change it? Just so you can say you are .NET compatible?

It is curious to read this words because I have loosen two possible and important customer firms - with very technician people in their staffs from old SAP partners usually - only by this cause in the last two months. I mean, I am 5 years experience tehcnician in Navision with complex, reliable, and demonstrable implementations, but this kind of firms want to have the state of the art in technollogy :?

My next goal, for example, is to define a new connector with Retail Management System and I want to avoid plain or XML files transfers. My first intention was to develop a new module in NAvision using ADO - as I said before I am very experienced with ADO against SQL Server and Oracle - to connect Navision with SQL Server HQ database.

I only wanted to check about other methods.

Thank you very much.

jesam

I conclude of your interesting information that programming C/AL code to connect to external datasources through .NET technology may be posibble but it is only worthy if you are obliged to do it. For example, If you have other .NET application and you have to access it.

The real problem is that Navision is a COM host and not .NET host. It is possible to make .NET components visible to .COM and so to Navision but it is not possible to make Navision understand .NET natively.
So if the component (database, MSMQ, ...) you are trying to connect to can talk COM, use it directly in Navision. That will be the most efficiënty because Navision does not have to rely on a translator (COM interop) to communicate.
If that component does not talk COM but does talk .NET, you can write a wrapper and make that COM visible. But remember that when you do that COM interop translates all communication from Navision to your target component.

If you lost clients because they want you to talk from inside Navision to SQL Server through .NET, then they really are not that a great loss. It are clients that do not understand technology but have big assumptions about it, they would only mean trouble.

DenSter

gjgarciasm wrote:

DenSter wrote:

If you have working code, why change it? Just so you can say you are .NET compatible?

...this kind of firms want to have the state of the art in technollogy :?

So you have a paying customer, that's the best reason, and you get to discover how to do this kind of stuff. Now I'm a bit jealous

gjgarciasm

DenSter wrote:

So you have a paying customer, that's the best reason, and you get to discover how to do this kind of stuff. Now I'm a bit jealous

Yes. I like to share and learn with the best masters

Don´t worry. I´m sure you have more and better customers than me.