Export Excel To Access Wizard HELP!!!

  • Thread starter Thread starter ibeetb
  • Start date Start date
I

ibeetb

I am at Step 4 of the Import Spreadsheet Wizard in Access and I can see all
of the fields listed from my Excel Spreadhseeet. The problem is, in the
wizrd, in the Field Options section, I can't seem to select the Column that
I do not want imported. The forst column from my Excel sprdsht that appears
in the Wizard is highlighted and it's Field Name is populated in the Field
Options box. When I try clicking on the fields I DO NOT want imported, the
wizrd doesn't recognize this. Even when I type the other field names into
the Field Name box, it actually overwrites that FIRST column. So, it wont
let me act on any column except the forst one. Anyone know how I can fix
this???
Thanks
 
This isn't a reply. It's the start of a related message. Why? Because after
signing on with my username and password, I am unable to start a new thread.
Clicking the NEW button causes a "hickup"-like warning beep, and then doesn't
do anything else. This is an intermittent problem. Sometimes it hickups,
sometimes it works. But I can post a reply to someone else's message, so
here I am.

So what's my issue? I have an Access app which contains queries used by an
Excel spreadsheet to refresh its data on open. It worked fine.....until I
rashly thought to add user-level security to my Access app. After reading
stuff by MS on its user-level security, as well as a couple of books by
Access MVPs, I thought I was ready. Even so, just to remain as plain vanilla
as possible, I did everything through the security wizard. I set up my user
in the pre-defined group that allows data adds, changes and deletes, but
nothing else. I set up myself in the Admins group.

Access is closed now, and security seems to work fine. So I open Excel and
click on the "allow refresh" message (forget the exact text). I get a message
saying I don't have permission to use the queries that do the refresh.
Puzzling. How does Excel know who I am? It didn't provide a logon screen, so
I never told it my logon name, never provided my password.

OK, never mind. Now I get a dialog box with "admin" filled in as the logon
name. I browse and point to the Access mdb that contains the security I just
added, the same one that contains the queries this spreadsheet is trying to
use to refresh itself. I don't provide a password for the admin account
because, as best I can remember, the security wizard didn't let me.

Going back to look, I see that the admin user isn't defined. Oh. I guess I
deleted it because some book I read said that leaving the admin user in place
was a big security breach no-no.

No worries, mate. I gave myself admin permissions by putting my own logon
name in the admins group. So I change "admin" to my logon name, provide my
password, point to the mdb and click. And what to my wondering eyes did
appear?

It might as well have been St. Nick -- and a St. Nick who knew squat about
Microsoft security -- because what I in fact got was a repeat of the message
telling me I didn't have permissions, to contact the administrator of my
database (that's me, folks), to get down on my knees and pray, etc, etc. We
users know the drill.

So now my Excel is worthless. I tried creating a new one from scratch, but
bumped into the "no permissions" roadblock again.

Being a hopeless optimist, I expect that, after man-days of work and several
messages from a helpful Access MVP, I will get this problem solved. And my
genuine thanks, in advance, to you hard-working guys and gals.

But jeez, this is MICROSOFT! Can't you do better than this? Does security
have to be this convoluted mess of linkages, literally a directed acyclic
graph of dozens of decision points, any number of options at each decision
point, and therefore many thousands of potential paths, with hopefully at
least one valid path from start to successful completion (although none
discovered yet)?

I've never been one for conspiracy theories, but to make this kind of mess
out of security, given the immense resources of time and talent Microsoft has
available .... and I'm talking about standard user and group security, whose
scope is restricted to MS Office products only .... not macro security, not
signed certificates, nothing getting into OS internals .... well, it's enough
to make a sane guy a little paranoid.

Not that MS hasn't written volumes about security. I've searched various
discussion groups for Access and for Excel, I've searched the knowledge base
and read several articles, I've used the on-line help in Access and VBA, I've
read a couple of books. There IS a path through this maze, I'm sure of it, if
only because what I'm trying to do is so commonplace that I would have heard
the uproar if it couldn't be done.

So ibeetb, my apologies for hitching a ride on your thread (and for
shamelessly mixing metaphors!) Oh what a tangled web we weave, when first we
practice to implement Microsoft security!
 
Hi,

Depending on what your Excel code is doing and what's in your queries,
it's often simplest to cut Access out of the loop entirely and instead
write Excel code that uses the DAO library to open the secured database
and execute the queries. I've pasted sample code at the end of this
message to show the sort of thing that's involved.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;192919


This isn't a reply. It's the start of a related message. Why? Because after
signing on with my username and password, I am unable to start a new thread.
Clicking the NEW button causes a "hickup"-like warning beep, and then doesn't
do anything else. This is an intermittent problem. Sometimes it hickups,
sometimes it works. But I can post a reply to someone else's message, so
here I am.

So what's my issue? I have an Access app which contains queries used by an
Excel spreadsheet to refresh its data on open. It worked fine.....until I
rashly thought to add user-level security to my Access app. After reading
stuff by MS on its user-level security, as well as a couple of books by
Access MVPs, I thought I was ready. Even so, just to remain as plain vanilla
as possible, I did everything through the security wizard. I set up my user
in the pre-defined group that allows data adds, changes and deletes, but
nothing else. I set up myself in the Admins group.

Access is closed now, and security seems to work fine. So I open Excel and
click on the "allow refresh" message (forget the exact text). I get a message
saying I don't have permission to use the queries that do the refresh.
Puzzling. How does Excel know who I am? It didn't provide a logon screen, so
I never told it my logon name, never provided my password.
<snip>

The sample procedure below opens a secured mdb and will work with minor
modifications in VBScript, VB and VBA.

If you actually have to automate Access (e.g. to if the queries contain
custom VBA functions), see e.g.
How To Automate a Secured Access Database Using Visual Basic
http://support.microsoft.com/default.aspx?scid=kb;EN-US;192919

Dim dbE 'As DAO.DBEngine 'Remove the apostrophes
Dim dbW 'As DAO.Workspace 'to change from late to
Dim dbD 'As DAO.Database 'early binding.
Dim rsR 'As DAO.Recordset

Set dbE = CreateObject("DAO.DBEngine.36") 'VBS, late binding
'Set dbE = New DAO.DBEngine 'VB/VBA, early binding

dbE.SystemDB = "C:\temp\xx\secured.mdw"
Set dbW = dbE.CreateWorkspace("Secured", "UserName", "Password",2)
Set dbD = dbW.OpenDatabase("C:\temp\xx\test.mdb")

Set rsR = dbD.OpenRecordset("Query1")
With rsR
MsgBox .Fields(0).Value 'demo only
'Add a record:
' .AddNew
' .Fields(FileName).Value = strResultsFileName
' ...other fields if needed...
' .Update
End With

rsR.Close
dbD.Close
dbW.Close
Set rsR = Nothing
Set dbD = Nothing
Set dbW = Nothing
Set dbE = Nothing



'Here's one that opens one secured database and creates an unsecured
one:

Const SystemDB = "D:\Folder\blah.mdw"
Const SecuredDB = "D:\Folder\Secured.mdb"
Const UnsecuredDB = "D:\Folder\Unsecured.mdb"
Const UserName = "User"
Const Password = "Password"

Dim dbESec 'As DAO.DBEngine
Dim dbWSec 'As DAO.Workspace
Dim dbDSec 'As DAO.Database

Dim dbE 'As DAO.DBEngine
Dim dbDNew 'As DAO.Database

Set dbESec = CreateObject("DAO.DBEngine.36")
dbESec.SystemDB = SystemDB
Set dbWSec = dbESec.CreateWorkspace("Secured", _
UserName, Password, 2) '2 = dbUseJet
Set dbDSec = dbWSec.OpenDatabase(SecuredDB)

Set dbE = CreateObject("DAO.DBEngine.36")

'Add code here to make sure UnsecuredDB doesn't
'already exist

Set dbDNew = dbE.CreateDatabase(UnsecuredDB, _
";LANGID=0x0409;CP=1252;COUNTRY=0")
'above string = dbLangGeneral

'Token manipulation of DBs to prove they're available
Msgbox dbDSec.Name & ": " & dbESec.SystemDB _
& Chr(13) & Chr(10) & dbDNew.Name & ": " & dbE.SystemDB

'Add code here to execute SQL queries
...

'Tidy up
dbDSec.Close
dbWSec.Close
dbDNew.Close
 
Thanks, John. I'll get into writing code like that as a last resort, but
don't think I should have to. Things were working fine yesterday morning.
Then I used the security wizard. Next thing, I can't refresh my spreadsheet.
I shouldn't need to write code like you have provided (code which, to be
intelligently written appears to require a deeper understanding of Windows
internals than I have, or want to have) just because I tried to password
protect my app.

I do appreciate your help, and that of the other MVPs and users more
experienced than I am. What I don't appreciate is an implementation of
password security which requires this kind of technical wizardry.
 
This is a known issue for ACCESS 2002 SP3. This issue is described in
http://support.microsoft.com/default.aspx?scid=kb;en-us;875252

There is a Hotfix available from Microsoft Technical Support for this
problem. Description of the Access 2002 post-Service Pack 3 hotfix package:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;841365

There also is a HotFix for ACCESS 2003 SP1 for similar issue.
Description of the Access 2003 hotfix package:
http://support.microsoft.com/default.aspx?scid=kb;en-us;837003

--

Ken Snell
<MS ACCESS MVP>
 
Alas, user-level access control is inherently complicated, whether it's
with database objcts in Access, or Windows files and folders , or
wherever. For it to be generally useful it has to be flexible, allowing
administrators to specify exactly what can be done by whom and to what;
and as you say, this leads to a huge number of possible combinations.

One approach that I think will work, as long as the security compromise
is acceptable: reinstate the "Admin" user, giving it the minimum
permissions needed to run the queries needed by your workbook.
 
Back
Top