By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,442 Members | 1,373 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,442 IT Pros & Developers. It's quick & easy.

unable to extract data from .mdb

P: 12
Guys,
Years ago I purchased an application, it has both an .mde and an .mdb file. I know that the code is in the .mde file and I don't care about it, but I need to extract the database tables from the .mdb file.

I've tried opening it and it says "That the user does not have permission to convert or enable this database".

I have tried linking to the tables and same issue.

Again I don't want anything to do with the code, but I do want all of my data that I have entered.

It may be workgroup security, not sure.

I can post the file if necessary. Any help would be appreciated as right now there are about 7 tables, and it would save me a ton of effort if the raw data could be extracted.

thanks,
dan

PS. I should also say that I purchased a password recovery program, but it said that the .mdb file was not password protected.

PPS. I should also mention that the shortcut for the link to the .mdb file had something like this as a target:

"C:/.../Msaccess.exe" /runtime /profile "xxxxx" "C:/Program Files/SomeFile.mde"

This may help divulge how to access.
May 28 '14 #1
Share this Question
Share on Google+
29 Replies


NeoPa
Expert Mod 15k+
P: 31,768
Dan,

You have the MDE & MDB back to front. Both files have the same tables in them. Only the MDB has the code. The MDE is more likely to be unprotected so is the easier one to look into for data.

It's possible the data is stored in a linked BE of course, in which case you need to determine the BE from the tables in the FE.
May 28 '14 #2

Expert 100+
P: 1,043
Did you try this link: http://mazamascience.com/WorkingWithData/?p=168
May 29 '14 #3

NeoPa
Expert Mod 15k+
P: 31,768
While the information in that link could, potentially, be used to extract some of the data, the link contains misleading and incorrect information and to benefit from it you'd need to be a Python programmer and possibly even be running on Linux.

I don't know for sure as I'm no expert in that area. Certainly, if you want an Access oriented solution then that wouldn't be where to look. Especially as all you need is already available from within Access in a much easier form anyway.
May 29 '14 #4

P: 12
NeoPa,

Well the file names are xxxx_Data.mdb and xxxx_Code.mde so that is what I was going by.

Dan
May 29 '14 #5

Expert 100+
P: 1,043
@NeoPa, true, but i was under the impression that an Access solution was not possible (from within Access).

Because that, obviously, is the preferred way to access that data.
May 29 '14 #6

P: 12
here is the files in concern, any help in extracting tables would be appreciated.

again I DO NOT WANT TO CRACK CODE, only get data from all tables!!

results can be emailed to dlenox at briery dot com

thanks!
dan
Attached Files
File Type: zip app_Data.zip (680.6 KB, 94 views)
File Type: zip app_Code.zip (2.79 MB, 96 views)
May 29 '14 #7

Expert 100+
P: 1,043
Installing mdbtools (see link i posted earlier) did not succeed in accessing your data.

Expand|Select|Wrap|Line Numbers
  1. luuk@opensuse:~/temp> mdb-sql app_Data.mdb
  2. 1 => list tables
  3. 2 => go
  4.  
  5. +------------------------------+
  6. |Tables                        |
  7. +------------------------------+
  8. +------------------------------+
  9. No Rows retrieved
  10. 1 => exit
  11. luuk@opensuse:~/temp> mdb-sql app_Code.mde
  12. 1 => list tables
  13. 2 => go
  14.  
  15. +------------------------------+
  16. |Tables                        |
  17. +------------------------------+
  18. +------------------------------+
  19. No Rows retrieved
  20. 1 =>
  21.  
May 29 '14 #8

NeoPa
Expert Mod 15k+
P: 31,768
The app_Code.Mde file has the following tables :
Expand|Select|Wrap|Line Numbers
  1. tblAcqType             Local
  2. tblCaliberGauge        ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  3. tblDispType            Local
  4. tblFirearmType         ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  5. tblImportReportNotes   Local
  6. tblInventory           ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  7. tblSetup               ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  8. tblState               Local
  9. tblStore               ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  10. tblTempAcquisition     ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  11. tblTempDisposition     ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  12. tblTransaction         ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  13. tblUser                ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  14. tblVendor              ;DATABASE=C:\Program Files\{SomeApp}\{SomeApp}_Data.mdb
  15. tblYear                Local
  16. z                      Local
Which of these are you interested in?

NB. I've obscured the app name for privacy reasons in case you don't want that made public.
May 29 '14 #9

NeoPa
Expert Mod 15k+
P: 31,768
I played with it some more but found that the security (which is workgroup security BTW.) was not able to be fooled so easily. Even when I relinked to the tables in code. No dice. Sorry.

One of the big problems with that setup was always that if you ever lose System.Mdw or forget the ID or password, then there's no way of getting back access to the system.
May 29 '14 #10

Expert 100+
P: 1,043
If you know a password to access those tables, this tool might be of help:
http://easyfrom.net/download/

or you could get an old computer with an old version of ms-access ;)
May 30 '14 #11

P: 12
Luuk,

I purchased a password extractor and it did not find a password associated with the files.

NeoPa,

I assumed that it was workgroup security, but since the app works and there is no apparent .mdw file I assume that the workgroup security settings may be passed from inside the code. Does that sound correct?

Dan
May 30 '14 #12

NeoPa
Expert Mod 15k+
P: 31,768
I was able to determine that there are no passwords associated with any of the tables Luuk.

If the system is working anywhere then that means there should be a file somewhere called System.Mdw (unless it's been renamed). I don't know where in the registry this file is pointed to but each installation of Access/Office Pro has a default specified. More than that I find it hard to recall. It was many many years ago I looked into such things.

The idea of passing security through via code doesn't sound correct at all I'm afraid. There must be a security file somewhere I'm pretty sure.
May 30 '14 #13

Expert 100+
P: 1,043
You are true about the passwords.
But it's strange i do see tablenames,
and no fieldnames.

It might be that this is an older version of access?
@dlenox: Can you give any more details on the version of access that was used to build this?
May 30 '14 #14

Rabbit
Expert Mod 10K+
P: 12,430
See if this works, make a copy of the mdb and open it in a hex editor and zero out the bytes from 0x18 through 0x95. Save it and run the recovery software again.
May 30 '14 #15

P: 12
Luuk,

Think that it is either 97 or 2002.

Rabbit,
zeroed out those bytes and access says "unrecognized format"

dan
May 30 '14 #16

Rabbit
Expert Mod 10K+
P: 12,430
Did you zero out the correct bytes? 0x18 and 0x95 are hex coordinates. It doesn't mean the 18th and 95th byte
May 30 '14 #17

Expert 100+
P: 1,043
i tried, replacing those characters, but same result:



oops, made an error, was accessing the file on my network drive, while i should have copied it to my local drive:
Now i get 'Could not connect':

May 31 '14 #18

NeoPa
Expert Mod 15k+
P: 31,768
Looking at How to use command-line switches in Microsoft Access it seems clear that no special copy of System.MDW is used, but that a profile file is specified. It may be important to post the contents of that file for us to look at.
May 31 '14 #19

P: 12
Rabbit,

Uh yea - I'm software engineer of 35+ yrs and worked in many number systems.

:)
Dan
May 31 '14 #20

P: 12
NeoPa,

getting back to the profile bit, not real up on it and I also see some info in the registry.

I understand that a profile overrides profile parameters and such, but did not think that it was used for security -what/how is a profile used in this manner?

dan
May 31 '14 #21

P: 12
Rabbit,

Ok I double checked and initially I did clear the 0x18th byte, redid it and double clicked and it is asking for a password now...

but previous password finder did not turn up a password...

dan
May 31 '14 #22

NeoPa
Expert Mod 15k+
P: 31,768
DLenox:
-what/how is a profile used in this manner?

If you post the contents of your file then we'll be in a position to analyse that for you. I've never used one, but I back myself to know what to look for. I would expect something in there will point to where the file you're using for security is found.
Jun 1 '14 #23

P: 12
NeoPa,

In registry under Computer/HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/AccessRuntime/8.0/Profiles is an entry for the profile name and the value given is the path under ..../Wow6432Node for the manufacturer.

Profiles are used to override 'standard' settings such as: Clipboard Formats, Report Formats, AppHelp File, Icon, Startup Screen, Titlebar and Speller options.

I've tried all combinations of data entries to use as the password, but so far no good.

Dan
Jun 2 '14 #24

P: 12
Update,

I tried an OEM software called AccessFix and it showed all the tables, record counts, etc... it did not ask for passwords and looked very hopefull.

Unfortunately the license fee is $199, so it is just too steep for me. But it gives me hope that either a lower cost share ware, or lots of personal work may get my data out.

dan
Jun 2 '14 #25

NeoPa
Expert Mod 15k+
P: 31,768
In the first post of the thread (The OP) you give the command line used. This specifies a file explicitly to be used as the profile, so anything else after that (EG. from the registry) is a red herring.

This is the file I've asked to see the contents of posted here (twice previously I believe). It's fine if you're confused but if you don't want to post it for any reason then please just say so. It's hard for me to tell what's going on when your responses don't respond to what's been said.

I'm sure if you read my earlier posts carefully they will make sense but if anything is confusing then please say so in order that we can better deal with the situation.
Jun 2 '14 #26

P: 28
I believe that, there is a System.MDW file together in order for you to open the data file.

http://support.microsoft.com/kb/305542
Jun 2 '14 #27

P: 12
NeoPa,

I'm not confused, the profile specified is NOT a file, but registry settings! I previously described the registry contents above, here are the Keys (without detail values):

Clipboard Formats: Default / HTML / ASP / Excel / IIS / Txt / RTF
Jet Options: Too many to describe here
Report Formats: Default / HTML / Excel / Txt / RTF / Snapshot Format
RunTime Options: Default / App Help File / Icon / StartupScreen / Titlebar
Speller: Ignore All Caps / Ignore Mixed Digits / Language ID /Suggest Always / Suggest Main Dictionaries Only

When running I believe that it is using the default System.mdw file as there is not one in the directory structure, nor reference in the registry.

Dan
Jun 3 '14 #28

NeoPa
Expert Mod 15k+
P: 31,768
I also believe there is a System.Mdw file somewhere, though it might be named something else.

The registry is where this filename/path may well be specified, but in order to tell you specifically where to look I'd need access to the profile - which I don't have. This is not as straightforward as a text file to pass across in a forum page unfortunately.

BTW Dan - Thanks for the explanation. I misinterpreted the documentation for /Profile and your post helped me to understand why you weren't responding as I expected (which can be confusing).

I'm afraid I don't have enough ready understanding of the old system to be able to answer all your questions. I was hoping for more clues that may enable me to find the answers first, but it seems that isn't as easy as I'd expected.

Good luck anyway.
Jun 4 '14 #29

P: 12
NeoPa,

I've checked my system path and it was not modified by this application, no system.mdw file exists in the application installation directory (only one level) so it appears to be using the default system.mdw file.

If that is the case then the .mdw is not being used in any way for security.

Not sure what else to say on this matter of the system.mdw. By using the AccessFix application it was able to access all tables and records, kinda enforcing what I am saying.

dan
Jun 4 '14 #30

Post your reply

Sign in to post your reply or Sign up for a free account.