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.

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.

"tudor" <(E-Mail Removed)> wrote in message
news:738EB03F-09B6-485A-AE82-(E-Mail Removed)...
> 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.

On Thu, 30 Oct 2008 02:56:10 -0700, tudor
<(E-Mail Removed)> wrote:

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....c77f430c7402db

How did you come to the conclusion?

-Tom.
Microsoft Access MVP



>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.

> 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?

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....

"Vadim Rapp" wrote:

> > 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?
>
>
>

On Thu, 30 Oct 2008 08:06:09 -0700, tudor
<(E-Mail Removed)> wrote:

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


>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....
>
>"Vadim Rapp" wrote:
>
>> > 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?
>>
>>
>>

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;

"Tom van Stiphout" wrote:

> On Thu, 30 Oct 2008 08:06:09 -0700, tudor
> <(E-Mail Removed)> wrote:
>
> 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
>
>
> >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....
> >
> >"Vadim Rapp" wrote:
> >
> >> > 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?
> >>
> >>
> >>
>

> 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.

> 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.

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.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Vadim Rapp" <(E-Mail Removed)> wrote in message
news:ep6yv$(E-Mail Removed)...
>> 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.
>