Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1.1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 326 Dynamics CRM
- 110 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 994 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
What is the point of CFront?
deltoid
Member Posts: 41
So I decided to have a look a cfront yesterday.
I was making calls to the cfront assembly from C#. After having a play with it for awhile I can not really see what the point of it is. Why would you not just use ODBC or similar so that you can use ADO and have a nicer way of dealing with the recordsets and data?
Or is cfront not really designed to be used from C# and instead designed for things like excel where you might be a bit more limited in what you can do in the way of programming?
Just after using it for a little bit to do some database calls / updates I realised that it is easier and more elegant using ADO to do it with ODBC than it is to use cfront.
I was making calls to the cfront assembly from C#. After having a play with it for awhile I can not really see what the point of it is. Why would you not just use ODBC or similar so that you can use ADO and have a nicer way of dealing with the recordsets and data?
Or is cfront not really designed to be used from C# and instead designed for things like excel where you might be a bit more limited in what you can do in the way of programming?
Just after using it for a little bit to do some database calls / updates I realised that it is easier and more elegant using ADO to do it with ODBC than it is to use cfront.
0
Comments
2) C/Front is backend independent - doesn't matter if you are connecting to SQL or Native DB
3) You have Options with text, not just numbers like when working with ODBC
This are the main differences...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Ok, so that is about it though? I've also noticed that you can get the "Wrong version of navision" when connecting to a different version database which is kind of a pain if you want to write a program which works for all databases which makes the backend independent part not all that great.
I can see your point with the other two options but it is still a pretty annoying way of going about it with all the record handles and all that sort of thing. You would think that considering it is CFrontDotNet they would have tried to make it be a bit more .netish for instance when your getting data from the database you put it in a recordset or something.
It is not problem of your application but of installed C/Front. It must have same version as NAV, but your code is not version depending...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Hmm, might need to try that out again when I'm at work next week. Pretty sure I was trying to connect to a 3.70 database from cfront for version 5.0 and it said I had the incorrect version. Might try that again though.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.