Converting an ADP project to VB + SQL Server + reports....Access 2003/2007

[Atlas]

Hy guys I have been managing successfully a medium size ADP project with
Access 2003 in the last 3 years and considering now if it is worth it to
switch to Access 2007, but reading bad news about it.

So just for what is done I was considering to convert the project to VB
something + SQL server + Some reports, and eventually, build new projects
with Access 2007.

Did anyone ever converted an ADP to a VB solution? Easily? Hardly ? using
what tools? Report manager?

Thanks

 

[Norman Yuan]

Converting Access app to other (VB, VB.NET...) means major re-write (its
extent depends how the Access app is written). The forms, reports, is
basically non-convertible, so is the code associated with forms, reports.
Even class modules (if you have them) may not be suitable to be directly
used in VB (not to mention VB.NET).

Make things worse, you also need to find/buy a reporting tool that can be as
closely good as Access'.

The think logic of converting ADP to something outside Access, and then
converting that back later to Access2007, to me, is even more difficult to
understand. If converting ADP to VB/VB.NET due to some reason is acceptable
(even that means major re-write, for example, considering ADP is coming to
its death soon), converting something from VB/VB.NET back to ADP is
definitely not wise thing to do.

So, you either converting ADP to other solution (VB, VB.NET...), or keep it
until its end of life, with necessary maintenance in following years, maybe
3, or 5, or even longer.

If you want to keep the app as Access app, you may one day to convert it to
a *.mdb with ODBC link to SQL Server once Access stops support to ADP (maybe
next release after Access2007, but no one knows for now). This conversion
might requires minimum changes, compared to any other converting.

If I were you, I'd keep the ADP as long as it goes with only really needed
maintenance. In the meantime, look into other technology as possible
replacement, including VB, .NET, Java, or even Access *.mdb.

 

[Atlas]

Hy Norman, maybe I've benn confusing.

I meant:
- keep existing adp and move to 2007 (did you try? If so what advises?)
- Develop new apps with VB something

 

[Vayse]

Haven't used Access 2007, so I can't comment there.
I've being using VB2005 for about a year and a half now, and have converted
some smaller projects. You're basically re writing your adp in a new
language.
At least the logical structure will generally stay the same.The main points
are:

1) Assuming you are switching to ADO.NET, your ADO data access will all
have to be re written.
2) Forms. No matter what you may have seen in the MS demos, the drag/drop
forms in VB don't work. They are only suitable for simple lists. The
datagrid does work well though. For standard data entry forms, you'll have
to write a lot of code yourself. Visual Studio 2005 forms are no where close
to being as good as Access!
3) Reports. I used the MS ReportViewer control. See www.gotreportviewer.com.
I like it, and its the most 'access-like' of any report designer I've ever
used. The only bad point is that it is a very new product, and therefore
difficult to get good support or help on it. If you check the official MS
forum, you'll find most of the questions are unanswered. So - its a nice
product, but if you come across any bugs or complex issues - you're on your
own!

Vayse

 

[Norman Yuan]

I stopped developing ADP for quite long time and have not doing one in
Access2007. However, I do not see there would be much issue for running
existing ADP (written with Access2002/2003) in Access2007. I tried
Access2007 once with one of my small ADP done years ago with Access2000, it
just runs.

If you want to develop a replacement for preparing the ADP's coming death,
you could use any technology you are capable of, among them, VB may be the
closest (however, VB itself is dying). No matter what technology you are to
use, all means entirely re-written (or almost).

So, I would

1. keep existing ADP for as long as it can, with only necessary maintenance.
It may be able to hang on for years, depending on OS, SQL Server, hardware
changes;
2. do not develop new project with ADP, unless it is a quick, small solution
(note, many small database solutions quickly grow to huge monster project
very soon);
3. start looking for alternative solution with the technology you are
comfortable with, or start learning new technologies.

 

[Atlas]

Back again, I've read your replies.

Well, I've asked because Office 2007 is out there and would like to know
what risks are involved if my clients switch to it... Do you think it could
be possible to install Office 2007 excluding Access, leaving installed 2003
version?

About switching to other solutions: VB Microsoft is so similar in all it's
flavours (VB Script, VBA, VB Access, VB ASP) that it shouldn't be a major
issue apart from event model and workbench capabilities (stuffing code into
objects or manage code automatically behind objects alà Access).

I went allready a bit through alternatives solutions (Gridex) to get decent
results.So it should not be a main concern.

Unfortunatelly Access gives RAD capabilities for quick start but hundred of
limits, so you end on better solutions.

I blame on Microsoft because in the past they've pushed and sold adp as the
professional solution to get to higher tiers and perspectives, while now
(after our efforts to build adp solutions) they're pushing it back to "local
access" solutions.... bah!