Converting adp file to VB 6

  • Thread starter Thread starter Deodiaus
  • Start date Start date
ADP are specialized Access frontend that directly connect to a SQL-Server as
the backend instead of connecting to a MDB file directly (one single file
for both the frontend and the backend) or by using ODBC linked tables to
connect to either a MDB file or a SQL-Server or both (database splitten into
a frontend/backend).

Excerpt for the difference of directly connecting to a SQL-Server - using
ADO - instead of using ODBC linked tables and passthrugh queries; the GUI
and the programming model of an ADP project is practically identical at 99%
to an ordinary Access frontend: same forms, same controls, same events and
same VBA language.

The difference is for accessing the data from the database: ADP use ADO
(instead of DAO) to directly connect to a SQL-Server and can retrieve data
directly from Views/Stored Procedures or queries that will run on the server
for the data sources of forms and controls. In the case of forms, it can
also directly update the database (following the change made by the user on
the form) even when a SP has been used as the record source for the form.

This is in contrast to a MDB file with ODBC linked tables where passthrough
queries are read-only and where queries sent to the server must be managed
first through the JET engine (ODBC linked tables).
 
A couple of hundred dollars for a tool is not expensive to give it a try.
However, based on my experiece on ADP, VB6 and .NET, there is simply
impossible to have such converting tool to turn a ADP project to a usable
VB6 or .NET application, unless it is "Hello world" stuff. I would not
bother to spend even $10 for such a tool. No matter what the tool can do,
you definitely still need a lot of rewrite and risk to get your thinking
being boxed in a unwanted application structure generated by the tool.

The true issue here are:

1. do you really know in detail what the ADP project does (there is OK if
you are not very good at ADP programming) and the business requirements that
justify the conversion (be it by toll to get it half way done, or simply
just re-write with latest technologies)

2. Are you good at the targeting technology you want to convert to (be it
VB6 or .NET). The choice that makes most sense (if you stick with MS) might
be .NET rather than VB6, or continue to use the ADP till its end of life.
 
Given that most Access applications make extensive use of subforms and
continuous forms, and VB6 has nothing remotely approximating either of these
features, it seems to me that any talk of "conversion", whether automated or
manual, is at best sloppy. Unless it's a very simple Access application
indeed, you're talking rewrite, not conversion.
 
I would make a costing on your assumption.

See becap's response below;

"Given that most Access applications make extensive use of subforms and
continuous forms, and VB6 has nothing remotely approximating either of these
features, it seems to me that any talk of "conversion", whether automated or
manual, is at best sloppy. Unless it's a very simple Access application
indeed, you're talking ****rewrite*****, not conversion."

That's always been my experience.

- Jaccess
 
I expect that the Report Definition Language (RDL) paradigm can be used to
"replicate" many of Access' forms and subforms including click-through etal.
These reports can be placed anywhere on the form/page in any combination
alongside conventional controls and managed by the ReportViewer control.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
 
ok, what I really want is a way to externalize my VB pages in my adp
project.
If for no other reason, then to use an text diff tool to find all the
changes to handle merging of code.
We find that we are losing to many code changes amonst different
developers.
Is there any quick way to do this?
 
Don't know if you are talking here about ADP or about VB6. There is diff
tool available from FMS for Access and it's supposed to work for ADP, too:

http://www.fmsinc.com/MicrosoftAccess/DatabaseCompare.html
http://www.fmsinc.com/Products/detective/ReviewersGuide/index.html

There is also a source control for Access from Microsoft using the VSS 6
(Visual Source Safe) but I don't know if it works for ADP as well:

http://msdn.microsoft.com/en-us/vstudio/aa700900.aspx
http://www.microsoft.com/downloads/...f4-a916-48c5-8f84-44b91fa774bc&displaylang=en

For the more recent Team Server or Access 2007, I don't know. There's also
an open source version control for Access but for it, too, I don't know if
it works with ADP:

http://sourceforge.net/projects/avc/

For VB6, I don't know.
 
Don't understand what you mean by "Externalize the VB pages from the ADP
project.".
 
Sylvain Lafontaine said:
Don't know if you are talking here about ADP or about VB6. There is diff
tool available from FMS for Access and it's supposed to work for ADP, too:

http://www.fmsinc.com/MicrosoftAccess/DatabaseCompare.html
http://www.fmsinc.com/Products/detective/ReviewersGuide/index.html

There is also a source control for Access from Microsoft using the VSS 6
(Visual Source Safe) but I don't know if it works for ADP as well:
Click to expand...

It does.

VSS would be the tool of choice for any VB6 or VBA (Office) project, warts
and all, due to its intergration with VB's unique development environments.

-ralph
 
I want the VB code to be external to the ADP file, so that I can track
my changes with windiff on a text file.
I tried to use the syntax
include: 'foo.bi'
but I got an error message
compile error
Invalid Outside procedure
 
I was thinking of just externalizing my vb files so that I could track
my changes with a diff tool.
is this syntax still supported and does it work ?
'INCLUDE: 'foobar.bi'

re:http://www.faqs.org/faqs/visual-basic-faq/dos/
Click to expand...

Ah, VB6 and VB-DOS are very different beasties. You can pretty much
completely ignore anything on VB-DOS. Anything written for VB4-32bit and
above should be close enough for VB6 - I wouldn't bother with anything
written for anything less that that.

There are better ways to do what you want to achieve. Mainly by using
Source Control applications...
 
Maybe it's possible to make a reference to some external VB6 module and use
inside a VBA application such as Access (like you can do with a MDB module
or even a VB.NET module); however, I'm not really sure if this will simplify
your task instead of making it even more complicated.

However, if you want to go into that direction, you should ask in a specific
new thread in a Visual Basic newsgroup.

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


I want the VB code to be external to the ADP file, so that I can track
my changes with windiff on a text file.
I tried to use the syntax
include: 'foo.bi'
but I got an error message
compile error
Invalid Outside procedure
 
I want the VB code to be external to the ADP file, so that I can track
my changes with windiff on a text file.
I tried to use the syntax
include: 'foo.bi'
but I got an error message
compile error
Invalid Outside procedure

====================================

OK Now I have a better idea of what you are after. And the answer is you
can't.

Your best bet is to use an Office Developers environment in conjuction with
VSS.

The reason is simply that the "VB code" (actually VBA in this case) isn't in
the ADP in the form that you are expecting. VB/VBA works somewhat backwards
from other programming languages due to its interpreted roots. The code that
you see in a VB/VBA editor/IDE while developing the application is actually
reconstructed for the programmers benefit. The actual working code is
opcode, it is stored as excode.

Even if you knew excode and could read and write it fluently, you would
still have problems because it often changess, although no apparent changes
were actually made in the visible code. (The sun and moon were aligned
differently when the tables and caches were re-assembled. <g>)

Check out some of the Office developer groups and see what they are using or
advise.
 
What are the other ways?
We have several developers working on an ADP file which is checked
into a revision control system ClearCase. Every month, we resynch, so
someone takes last month's release, and merges his and everyone elses
changes into the release. This is painstaking work, and some things
get omitted. One thing that would greatly help with this process is
if we could see everyones work under a diff tool like windiff. In tis
way, we could compare our final version with everyone elses.
Unfortunately, for binary files, reading ADP format is difficult.
I noticed that there is an export/import option. I can take a module
and export it as XYZModule.bas. This would be good, except that when
a file is imported, the names default to something like Module1
instead of our desired and referenced [in other sections of the ADP
file] XYZModule imported from XYZModule.bas One has to manually
rename Module1 to XYZModule, which is a lot of work for 700 modules.
 
What are the other ways?
We have several developers working on an ADP file which is checked
into a revision control system ClearCase. Every month, we resynch, so
someone takes last month's release, and merges his and everyone elses
changes into the release.
Click to expand...

That is an extremely ugly process.
This is painstaking work,
Click to expand...

I'm sure it would be.
...and some things get omitted.
Click to expand...

Which would pretty much be a given.
One thing that would greatly help with this process is
if we could see everyones work under a diff tool like windiff. In tis
way, we could compare our final version with everyone elses.
Click to expand...

Ah no, one thing that would help would be changing your process. It ain't
gonna matter what resources you throw at this problem, it is your processes
that are screwed.

- Compartmentalise your aoftware.
- Only one preson works on a module at a time.
- All code is checked out, worked on, then labelled and checked back in.
- No code is left checked out for more than a week - preferably no more than
a day.
- Test all changes much more regularly.

And if anyone does what you are saying - a month's worth of work without
integration, you smack them across the head with a steel ruler and tell them
never to do so again.

For the moment, forget about the software. Fix your processes.
 
Back
Top