ADV Conversion to .Net

[tudor]

Hi,
We've now come to the conclusion that ADPs and Access are not the best
platform moving forward for our database front-ends... Has anyone converted
or migrated to VB.NET - and if so, how did you do it?
I'm rather hoping that we can slowly migrate forms within our Access ADP
into VB.Net as we need to - and use a bit of both (ADP and VB.NET) until
eventually we have it complete.
I know there's an Interop Toolkit
(http://msdn.microsoft.com/en-us/vbasic/aa701259.aspx) that seems to help
with VB6/VB.Net interoperability - can this be used with AccessVBA and VB.NET?
Any help or guidance would be really appreciated.

 

[Norman Yuan]

The only practical approach to "convert" or "migrate" from ADP application
to .NET application (Win form or web app?) is to know .NET very well and
rewrite the whole thing. .NET and ADP are so different that no tool can do
the magic for you. Of course your BE stuff (tables, views, SPs....) are most
likely reuseable with little change. I do not see slow migration is a good
way to go, unless you mean building new .NET app functionality by
functionaliy while the ADP remains. Yes you can build .NET components and
expose them through Interop, so you can use it in ADP. But if your goal is
to let the APD die ASAP, then this does not make much sense.

 

[Tom van Stiphout]

On Thu, 30 Oct 2008 02:56:10 -0700, tudor

Yes the Interop toolkit is very cool and can help you do a slow
migration. It can indeed be used with Access. See my earlier post
here:
http://groups.google.com/group/comp...1/c4c77f430c7402db?lnk=st&q=#c4c77f430c7402db

How did you come to the conclusion?

-Tom.
Microsoft Access MVP

 

[Vadim Rapp]

Yes the Interop toolkit is very cool and can help you do a slow

migration. It can indeed be used with Access.

..Net involves different thinking and different phylosophy. Of course, "The
determined Real Programmer can write Fortran programs in any language", but
then why migrate at all?

 

[tudor]

Hi - thanks to all for comments. The real reason we're considering moving is
that we're sick and tired of Access not really moving forward (we're firmly
into cash-cow releases, it's not being kitted out to take advantage of any
..NET, etc. etc.), Access 2007 ADP performance issues and bugs, and rewriting
business logic in Access/VBA some of which already exists in .NET (we have a
few ASP.NET web sites, and there's lots of duplicated business logic between
Access and .NET - double development effort and double maintenance).
I'm thinking the slow migration is an option as we'll write new stuff in
VB.NET and maybe migrate anything from Access to which we need to make
significant changes.
ADPs were wonderful in XP/SQLServer 2000 - but they're dead now - and I
don't want to pour more time into developing on a platform that is not
moving....

 

[Tom van Stiphout]

On Thu, 30 Oct 2008 08:06:09 -0700, tudor

Yes I agree the writing is on the wall. It's too bad MSFT couldn't
just come out and say that: "ADP will be deprecated from A2007 onward
and we recommend customers using this technology to find other ways to
write their applications. Here are some suggestions <msdn articles
follow>."

-Tom.
Microsoft Access MVP

 

[tudor]

It really is too, too bad. We still find ADPs the fastest to develop in
(Access 2003 only!!). We've written a few mini VB.NET apps already and the
reality is that they take a LOT longer to develop/compile/test - maybe 3
times as long. ADPs were wonderful for getting something up and running
quickly in the back office... But we're committed to .NET for the web and
that is probably our most important application strategically - and there is
a big long-term cost to maintaining two sets of application logic that aren't
interoperable.
I've always thought MS made a mistake not taking Access further as a
front-end development tool for SQL Server databases - it was a fantastic RAD
front-end that has now been pretty much ignored in the ever-bloating Office
suite - and are now left orphaned to the .NET world and the last two releases
of SQL Server. MS would be making a BIG admission of omission if they were
more clear about where Access/ADPs are(n't) going, and I agree MS should be a
lot more clear with their development community. A bit more attention to
helping with migration would be helpful but I suspect that anyone writing
ADPs have been orphaned by both the MS .NET teams and the Office teams as
neither prototypical developers nor prototypical Office users. I could rant
away for pages... Lesson: choose your development tool VERY carefully.
At least MS isn't likely to drop off the face of the planet any time soon,
and we aren't using FoxPro! One just has to read some tea leaves to predict
which of their myriad solutions they're going to vote off the island and hope
that there are enough people using it that you're given a decent migration
option.

end mild rant;

 

[Vadim Rapp]

Yes I agree the writing is on the wall. It's too bad MSFT couldn't

just come out and say that: "ADP will be deprecated from A2007 onward
and we recommend customers using this technology to find other ways to
write their applications. Here are some suggestions <msdn articles
follow>."

I doubt they are so sure themselves. I think with their size, they are now
more like separate kingdoms, each with its own agenda. It's not even for
sure that only one kingdom will eventually win. For just one example, Visual
Studio team creates setup and deployment functionality that contradicts what
Windows Installer team is doing, and their actions are unsupported by
Installer. Yet, both teams continue their developments, and there does not
seem to be a question of which approach will survive.

In Access team blog, you can see that ADP's as still mentioned in new
patches and service packs they are working on. I think it's significant.

 

[Vadim Rapp]

I suspect that anyone writing

ADPs have been orphaned by both the MS .NET teams and the Office teams as
neither prototypical developers nor prototypical Office users.

....as well as anyone working with spreadsheets, text documents, managing
their personal finances, playing simulated airplane on their pc..... we are
just not exactly like the characters in the Microsoft's own magazine ad, who
apparently have become their most important users.

 

[Sylvain Lafontaine]

Until they correct the basic flaws of ODBC linked tables, for example the
lack of a read/write passthrough queries, the ability to use a SP for
subreports or simply the lack of full support for Unicode, I don't think
that they will ever drop ADP for good.

However, if they resolve these issues; it's likely that it will disappears
but then, it will be easy to switch back to the other format and everyone
will be happy.

 

[Vadim Rapp]

BTW, here's a piece from Microsoft that I think is quite indicative of their
ways to find out what customers think. They sent a survey about gaming. The
survey goes like this (simplified):

Do you own a console? choices: yes/no. Answer: No.
how many times you played on console last month? choices: 1-3-5-10
how many dollars you spent on console games last year? choices: 100-500-more

and so forth. Easy to see how it's impossible to not make the conclusion
that their console business is undergoing a boom, completely unrelated to
the reality.

 

[a a r o n . k e m p f]

I agree, ADP are the best platform in the world, bar none.
The only thing that's even close to it-- is dreamweaver, using Classic
ASP.

 

[a a r o n . k e m p f]

I agree- sprocs in MDB / ACCDB are just unusable

 

[a a r o n . k e m p f]

what are you talking about dude

if you're using spreadsheets, you should have SQL Server Analysis
Services, and that kicks Access but.
Do you honestly let people edit / enter data into a spreadsheet, and
then you're mad that it doesn't live in TSQL?

I think that MS needs to take the ADP paradigm and apply it to EXCEL.
When someone types in data into a spreadsheet, it stores the data in
SQL Server.

Now _THAT_ would help us to get rid of spreadmarts (which are the bane
of sane people)

 

[a a r o n . k e m p f]

that's just not true.

MDB / ACCDB doesn't do half the stuff that ADP does.
SQL Server Management Studio doesn't do half the stuff that ADP does.

-Aaron