VBA/VB6 vs VB.net

[GPO]

A few years ago my mate and I developed a neato little program in VBA/VB6
that could run either as a MS Access 2000 (or later) mdb application, or as a
VB exe that linked to a SQL Server database.
The bulk of the code in either case was common. We just exported the
relevant modules from VB6 and imported them into Access. We even had an SQL
parser that would convert tSQL into an SQL dialect that access could run. All
up it meant you could maintain the two as if thery were a single app, making
changes in one place to update both.

Now the people who manage the corporate direction of programming in our
organisation have said that all VB6 apps have to be converted to vb.NET. That
on it's own is bad enough, but my question is this: Does Microsoft offer the
same seamless integration between an Office scripting language and VB.net as
it did with VBA/VB6? If we cannot keep common, the code that should be
common, then we essentially now have two apps to maintain, and all the
problems that go along with that.

Has anyone else dealt with this before?

 

[Douglas J. Steele]

You cannot use VB.Net instead of VBA in Access. However, can you not create
an ActiveX COM object out of your VB.Net application and use it in VBA? You
could have done the same in VB6, so that you wouldn't have had to import the
code into Access at all: you'd simply have had a reference to your VB6 EXE
or DLL.

 

[GPO]

That sounds like a great suggestion. Many thanks.

Now that I think about it, I think the reason why we shied away from doing
it in VB6 was that the MS Access version of the app was fully contained in a
single .mdb file, no exe or dll to worry about. This was an advantage because
we deplyed it to about 40 organisations, all with their own IT policies. Most
were happy to allow staff to install/run an .mdb app, but many were extremely
wary of allowing in dlls and exes (go figure!). Dlls and exes added a layer
of complication to installation that we wanted to (and managed to) avoid.