ADO.NET with MS Access

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is it possible to use ado.net with an MS Access FE? If so, how
My reason for inquiring is that I currently have Access FE with SQL server 2k BE and want to move the business logi
to a middle tier. I was advised to skip straight to .net classes
Thanks for any comments
SMK
 
Is it possible to use ado.net with an MS Access FE? If so, how?
Click to expand...


Do you want to execute your methods within the FE? Or do you want to query
the backend tables?
 
What you are trying to accomplish is not easy. Access has
traditionally allowed developers to build complicated applications
that do a lot of comlex things very quickly and easily. However, one
of the significant downsides of Access/Jet development is that all
that code you've written in the FE is simply not portable. You're
stuck with doing a complete re-write when you want to migrate the app.

Access apps that were written with eventual migration in mind are
constructed with the business and data access logic contained in class
modules (which can be simply copied to VB6 classes). However, it
doesn't sound like yours was. I'm thinking you're looking at a
complete rewrite. One of the downsides is that this won't be painless.
Neither asp.net nor winforms possess all of the features and
functionality of Access forms and reports (things like subforms, bound
controls, the expression service, etc).

-- Mary
 
Mary: THanks for your comments. Yes, I agree this will be far from painless. In fact, I have been researching and working for over a year now trying to sort out what my next step is. Every time a move one direction, I discover what the pros and cons are. THen I try another tactic, same results

But I have tried and tried to make Access work and I become convinced that the long term picture needs a different solution. I know I am facing a complete re-write and trying to ease into that by gradually unbinding some of the Access forms and moving the coding out of Access

I will say of Access, however, that I think it has some great features and is an excellent prototying product. In fact, I don't plan to ever completely discard it because it is great for trying new ideas, letting users comment, and making many changes before you solidfy requirements for development

By the way, I have your book which has been a life saver and extremely helpful. It has helped me to figure out where Access should fit in all of this and solidified my decision to gradually ease out of Access. My app runs a business and the complexity of that plus the fact that it needs to expand beyond one little office seems to drive me from relying on Access entirely
Regards
SMK
 
Everything you say is true. Even today, being comfortable with .NET
and SQL Server, if I want to get something up and running quickly,
I'll still use Access. In terms of migrating your monster app, are
there ways that you can logically partition it now, and gradually
migrate chunks of functionality? For example, if there's a web piece,
perhaps you can build just that chunk and move it away from Access? Of
if there's a lot of functionality embedded in modules, can you move it
to class modules and adopt a more object-oriented approach to its
functionality? If you can provide a logical separation between the
tiers now, then the eventual physical migration will be easier later
on. If you do the class module thing, then when you want to move to
..NET, you can copy the classes to VB6 and run the Code Advisor on the
code, which will help you convert it to VB.NET more quickly:
http://msdn.microsoft.com/vbasic/technical/upgrade/guide.asp

--Mary
 
Is the article mentioned on your posting available elsewhere. When I
try to access the link is dead.
 
Back
Top