I have a VB windows forms application that accesses a Microsoft Access
database that has been secured using user-level security. The
application is being deployed using No-Touch deployment. The objective
in utilizing this new deployment method is to reduce the maintenance
overhead as well as making it easier for my users to setup and run the
application initially. I have VS 2002, Windows XP, Access XP(2000
format).
He is my problem. Since the database is secured, I must provide a way
for my users to change their passwords. Also, some forms access tables
that certain permission groups do not have access to. So instead of
letting the error come up when they open the form and try to update,
at logon I am searching through the groups that the user belongs to
and locking out access to these forms if they do not have permission.
The only way I know to do these 2 functions is to use DAO. However,
for accessing and updating my data, I'm using ADO.NET.
So I have included DAO 3.6 using Project>>Add References>>COM tab in
the VS project.
I No-Touch deployed it and most users are working, running the gamut
from Windows NT 4.0 to Windows XP, admins and non-admins.
Then there was this 1 machine, then another...It is now 3 machines.
Each have different errors or none at all(app won't even open). On 1
of the 3 I have a strong belief due to the nature of the errors that
it is just something wrong with the machine. The user has reported
problems with the unit before my app was placed on it.
Now on the last 2 machines....1 is Windows NT 4.0 and crashes before
the app even opens, the other is Windows 2000 and has the error of
"QueryInterface for interface DAO._DBEngine failed.". I thought that
maybe installing MDAC would work. So I put the version of MDAC that
all the machines have including mine(2.6) on both, and same error. I
have also made sure that the Jet 4.0 engine is setup and current. I
thought that maybe the dao360.dll was not properly registered or set
up which is why I did these steps. No change. I checked the registry
and "HKEY_CLASSES_ROOT\DAO.DBEngine.36\CLSID" is present. I don't know
if that even matters. Also, I have a VB6 app that uses dao360.dll on
these machines and this VB6 app works. The more I work on this, the
more I think it is not just this machine, but rather something(s) I'm
doing wrong in .NET(also taking into account the 2 other users and
even more mentioned below). The framework version on these machines
is the same as mine 1.0.3705.
NOW HERE IS THE DOOZY:
Since this is No-Touch deployment I am accessing the app by clicking a
link in the browser of course(IE 6.0). It errors. If I instead browse
out to the folder using Windows Explorer....IT RUNS FINE ON BOTH
MACHINES!!? My limited knowledge about .NET No-Touch doesn't help me
understand this much. This re-enforces my belief it is me and not the
just the machines.
But if I understand right, doesn't No-Touch put the assemblies in the
GAC. Maybe I can force what I need into the GAC or something along
those lines. How could I remedy/do this? It seems that on the NT 4.0
machine it can't find any assemblies even to open and the Windows 2000
machine just can't find the DAO assembly.....but I'm probably way
off??
Here is the .NET code and the spot that errors out when No-Touch is
used:
Dim wks As DAO.Workspace
Dim theEngine As New DAO.DBEngine()
' Open the workspace, specifying the system database to use
'***************** error
theEngine.SystemDB = AccessDatabasePath & AccessWorkgroupName'this is
the line that errors
'***************** error
wks = theEngine.CreateWorkspace("", UserName, OldPassword)
' Change the password for the user Admin
wks.Users(UserName).NewPassword(OldPassword, NewPassword)
ChangePassword = True
'I have a loop that gets the users permission groups here
As a matter of fact if I try to reference any of the DBEngine's
methods or properties it errors on this machine.
Also,
I tried latebinding:
Dim theEngine As DAO.DBEngine
theEngine = CreateObject("DAO.DBEngine.36")
and it errors with a message: "Specified cast is not valid."
Here is the VB6 code that works:
Dim wks As DAO.Workspace
Dim usr As DAO.User
' Open the workspace, specifying the system database to use
DBEngine.SystemDB = theSysDB
Set wks = DBEngine.CreateWorkspace("", UserName, OldPassword)
' Change the password for the user Admin
wks.Users(UserName).NewPassword OldPassword, NewPassword
DAOChangePassword = True
WHAT I'D LIKE TO KNOW:
I know that .NET is trying to avoid "DLL HELL" and that by using COM
items I'm throwing myself back into it. I'd love to use ADO.NET(or
anything else in the framework) to do what I'm doing with DAO
but....how....can it even do it(getting user group and password in
from *.mdw)?
How does No-Touch work, for instance, the point I made above about the
app running from the folder and not the browser, could the method of
No-Touch deployment be the problem, and if so how can one fix it,
something like forcing stuff into the GAC or other method? Basically
why does it work when executed from the folder directly, but not from
the Browser using No-Touch deployment on this particular machine(yes I
know you would have to see the machine, but what COULD it be, maybe
just some things for me to check)?
Even if ADO.NET or other item can do what the DAO is doing I'd still
like to know the way to get COM items to work with the "No-Touch"
philosophy. Meaning little to no maintenance. In addition to the 3
user mentioned above I have had others with errors. I was able to
resolve them simply by installing MDAC 2.6 or later. This kind of
defeats my purpose.
Is it possible to deploy(via No-Touch deployment) projects using COM
items and still fully reap the benefits of No-Touch in every case(ie
no DLL HELL)?
Is there some special tricks that can perhaps still use COM items and
avoid "DLL HELL", or is it that if you go using COM items your just
stuck taking the risks?
If there are tricks, what are they?
If no tricks, then if COM must be used, are there precautions that can
reduce the problems?
Are there any books, etc. that are very thorough on "No-Touch"
deployment
Any other pointers would be most appreciated. Thanks in advance.
JL
