I am completely perplexed.
A colleague's got a database issue. I noticed that the (internal) software that created the local database file with the problem, uses programmatic access to MS JET, which meant an easy first step was to see if MS Access (2010) was happy with the database - and then fix, export/import or repair, as a first step.
I copied the stand-alone local Jet data file to a non-networked virtual machine (so no chance of external data), and MS Access opened the db file easily, but I can't make sense of what I'm seeing.
MS Access is configured on that system to show all hidden and system objects, confirmed since the Access system tables in the file are all visible and can be opened. These are my observations:
The object browser lists the usual MS system tables, and a bunch of SELECT queries (which look correct) of the form SELECT (FIELD LIST) FROM (OTHERTABLENAME) WHERE (FIELDNAME=VALUE), nothing more.
The select queries show the usual grid with valid data records when opened, and the data looks correct as well.
No data tables with the given names are showing in the object browser interface.
The given names are listed as objects of the database, in the system table MSysObjects.
So..... the underlying data tables ARE named in MSysObjects, and seem to be true data tables... but they are NOT being listed in the object browser and I can't figure how to open their datasheets (although MS Access' system tables are, and "Show hidden/system" are both enabled)... and the tables surely do exist in the file since an apparent SELECT query is pulling their data from them, and the file is on a clean non-networked machine with no other sources reachable.
Any ideas? I want to check the underlying data but ... whats going on?
When I examined your database, I discovered the reason you can't access the tables normally is because the authors of the internal application which created the db file implemented measures to prevent normal access.
I advise you to contact them and your managers to get authorization and assistance to view the data.
Also, please be cautious with this question. A suspicious person might uncharitably interpret your question as a disguised request for hacking help. Please note I am not accusing you of anything underhanded ... simply asking you to notice how your question might be perceived. And, if that were to happen, I don't know what the consequences would be on Stack Overflow, but I can't imagine it would be good. So please be careful.
Related
Apologies in advance if this is a dumb question, but with Google's release of "File Stream", does anyone know how this would impact MS Access dbs stored on it?
My "setup" is that I have users that are routinely using an AccessDB that was built for them years ago, and I'm trying to replicate it in MS SQL. Not by my choice, the file is stored by the clients on a Google Drive: Which essentially means that I can only look at the vba and do testing when the clients are not using it. The clients also use Google's sync to access the file.
So my question is two-fold. First, if the clients are looking to move to File Stream and asked how this would impact their ability to use the Access file (I have no idea). Second, will File Stream make it possible to have multiple users on a MS database without causing conflicts or problems? Would I still need to make sure that I have exclusive access to the file while making changes to the vba code?
Thanks in advance!
UPDATE: Over 1k visitors with the same question and updating the description as asked by the person who marked this as -1 (now marked -2 without feedback) but the only question answered is that having multiple users simultaneously isn't sound. What remains is why a single user scenario can cause corruption of the file stored on stream: Compact/repair fails at least when the file is large.
Based on experience, you need to make sure only one person has the database open at a time. If two people open the database, then changes will not be saved. Try to find a different solution if possible.
The MSAccess database engine is fundamentally based on the database primitives provided by the MS file system. Including the record read/write/lock primitives. (Bet you didn't even know that MS operating systems had a native database system!).
Access records and tables are NOT filesystem records and tables, BUT -- the Access database system of records and tables are built on top of the native system of record locking. (The native system doesn't, and never had, any thing smaller than file-level authentication and permissions, so Access built a whole new system on top).
That means that any file system, or any network file system redirector, which doesn't support record locking like the MS file system and the SMB protocol, can't support simultanous multi-user access to an Access database.
I'm not familiar with Google FileStream, but I assume that it's a way to access binary objects using a database API? Normally that means the API doesn't look inside the binary object: so it can't be locking individual sections of the file for R or W or RW: that means you can't R part of the object while somebody else W a different part: that means you can't share access. ... and even if File Stream means something different to Google, the chance that they support SMB inside it is slim to none, right?
I am trying to connect MS Access to a MySQL database backend - using the windows "Set up data sources (ODBC)" command allows me to connect to my database fine, but will not save the DSN file for some reason.
I've tried to get around it by manually creating a DSN file which looks like (with the actual data instead of the ***):
[ODBC]
DRIVER=MySQL ODBC 5.1 Driver
USER=****
PASSWORD=****
SERVER=**.***.**.**
DATABASE=cl39-beech
However Access throws up the message
ODBC--call failed.
[microsoft][odbc driver manager] data source name not found and no default driver specified.
Any thoughts on how to get around the problem(s)? I'm not too worried about the first one if I can manually create the DSN file, but need to work out where the second is going wrong!
Simply create the working link from Access like you did in your first step. When the ODBC manager from Access launches then simply create a file data source.
Check that the linked table works by opening the linked table in Access to ensure the connection works and you see data.
Now, simply grab/pull out the connection string saved for that table like this in the debug window (hit ctrl+g to launch VBA IDE and jump to command line).
? currentdb.TableDefs("dbo_customers2").Connect
The debug window will then out put the correct connection string. (so in above, replace what I have with the name of the WORKING linked table).
It is the above connection string result that you can use to re-link a table.
A suggested code example for the above string to re-link tables can be found here.
So don’t bother with trying to use a DSN, as there is often a zillion issues such as where you have to place the file to work etc. The above approach means no DSN is required.
edit:
Edit:
In most cases, you likely don’t need any code. Remember, once you linked the Access tables, then the DSN is in general NOT required. Access linked tables “remember” their settings.
So you really only need such code if you not going to “manually” use the ODBC manager from access to link the tables.
Thus, the code ONLY need to run “one time”. So you on your development machine simply place the code in a standard code module and while in the VBA editor hit F5. As noted, if you ALREADY linked the tables, then you don’t need the DSN anymore anyway (it is only used “during” the re-link process and the settings in that DSN are transferred to each linked tables.
So you don’t need to run the code in some form – it is a “one time” thing you do much like designing a form. You don’t re-design forms on application startup, nor do you need to run some re-link code ONCE the tables have been linked.
In most cases such re-link code is ONLY required if you going to CHANGE the back end database (say from developer back end to the actual production back end database). And thus I suppose you could make a form with a button on it to re-link, but as a general rule you don’t need that code to run each time the application runs.
Once tables are linked then your forms and reports etc. should work as if such tables were regular “local” access tables. So this re-link code is really a “substitute” for you doing the manual linking to the SQL server tables. However ONCE you done a “manual” link, then the original DSN is not required. The re-link code thus in “most” cases is to allow you to re-link the front end database to a back end database of your choice, or in those cases in which you are supporting a client “far away”.
If you are developing “off site” then your linked tables are to your local copy of MySQL. When you send a updated “next great” version of your application to the customer site, then your table links are wrong, and on startup you need to run that re-link code to correctly link the tables to their back end. A “great” way to do this is to ALWAYS have a text file in the same directory as the application. Your application on startup can read that text file, and if the connection string is DIFFERENT then the existing connection, then you call + run your re-link code with this new connection string. Thus you don’t have to be on the customer’s site to roll out updated software. Next time the application runs, the connection strings will match and thus a re-link will NOT be required on startup. So re-linking is a “one time” type of deal here.
There are a BILLION different use cases here. What works for me may well not work for you. It not clear if you are working “on site” (so re-linking of tables is likely NOT required), or you developing off site with your own copy of MySql running (and thus you linked tables point to the wrong server). Or you are developing on site, but DURING development, your front end tables are linked to a “test” copy of the database as to not accidently “mess” with the production data.
So the code belong in a standard (non class) code module. As to when you need to run such code will depending on the billion different possibility’s (so it kind of like asking me to tell you where your shoes are in the morning – I have no idea and never could have an idea). But I can tell you that you should put shoes on when you go outside!
So if your linked tables are now working, then your application should be compiled to a accDE, and then that accDE should be distributed to each computer that requires this application. If they are on the same network etc., then no code or re-linking of the tables is required. On the other hand, if you are developing off site, or the application has to be distributed to several different companies then likely EACH company will have a different server location as to where MySQL is running and thus you need to re-link in each of those cases.
So it is possible that you may well not need ANY re-linking code. If you are “on-site”, then once you linked those tables, then your application should run on ANY computer without needing any re-linking code or having to run this re-link code.
So once tables are “linked”, access remembers that setting and it is permanent.
I've just been assigned the task to create another Access DB whose data is a subset of the master DB. I didn't build the original DB and I'm just stuck in trying to create this functionality.
Depending on a Boolean value (which I will have to integrate into the DB) each entry will dictate if all the entries data will be shared or if only a portion of the data will be shared. By sharing I mean transferring the entries into a mirror DB that is located in a folder that a wider group of people has access to.
I don't know how to even start but I'm guessing that the relations structure that the person who built the DB will be helpful for when I erased an entire entry in the DB it erased all data in other tables related to my entry as well.
For added "fun" I'm suppose to manage a C.R.U.D. system for this subset in case either a person accidentally clicks on the share button (Create) and wants to unshared the data (Delete) or when part of the original gets updated and the mirror then needs to get updated as well (Updated).
I'm hoping to get a few good ideas as to how to proceed.
Limitations and Info that I see might be relevant.
-The original DB is located in a folder whose permissions are restricted to people entering data.
-Can't use third party applications that require an install.
-The mirror DB does not have to updated automatically when the master DB updates. It can be restricted to when a user clicks a button called "Updated Mirror DB". (Only if this would provide a simpler solution)
-The process can be as slow as molasses in winter as long as it is robust.
-I have decent VBA skills when it comes to working in Excel but it lacks when related to Access.
-Users who create and manage the data have read and write access to both the folder that the master DB is in and as well the mirror DB.
-Using Access 2007 - 2010
Thanks everyone for take a look at this. If you would require more info to provide assistance please just ask and I'll do my best to acquire it.
Seeing as you have decent vba, and you're limited to apps which don't require an install, I suggest you do it as an excel vba app. VBA has all the functionality you'll need to copy databases from one spot to another on the file system, compact and repair (adox), drop tables you don't need, insert/update/delete etc.
Depending on which info you need to persist to the mirror db, it may be easier to simply make a copy of the master db and delete irrelevant tables (if it's only certain tables you need to mirror). If it's a subset of data in each table, you may find the best way would be to make a template db, which is a copy of the master db but with no data, then create a vba process to copy the template db, create linked tables in this one back to the master, then run sql to insert into the local tables select (whatever data you need to mirror) from the master tables.
All of this can be done in vba, and your users end up with an excel interface which will be very familiar. Good luck.
I have an Access 2003 database using MS-JET linked tables (that is, there are two *.mdb files). The overall task is to move to SQL server. However the existing databases have multiple fields with spaces and other characters that upset both of the Access migration wizards. So the intermediate task is to make a version of the existing mdb's with updated field names.
"Simply" changing field names in the UI mdb file doesn't work, because of the linked tables being read-only in that mdb. Updating the Data mdb file field names first doesn't work because the UI mdb then throws a wobbly on startup and Access gives up.
I'm looking for suggestions, but options I can see are:
re-integrate the Data mdb back into the UI one, do the updates, then re-export the data. Seems very risky to me (system is live, don't want to play with data any more than strictly necessary).
I've looked at several answers here relating to changing ODBC details with VBA code, which is interesting, and I can see how I might be able to programmatically edit the linked tables' names. Is this going to work? Is there a better way?
Unlink all linked tables, then edit in UI mdb the remaining forms, reports, queries (but would that work??) and edit the Data mdb fields, and finally relink everything. Will it fall apart?? ... seems likely.
Any suggestions?
Ruth
I go through this process every time I take over an existing Access application -- I have to bring it up to my own standards for naming conventions before I do anything significant with it. Recently I built a quick-and-dirty utility to rename fields. It was made for me and has very little error recovery, and a UI that is ugly, but it might be faster than doing it yourself.
See what track name autocorrect offers. How Name AutoCorrect Works in Microsoft Access
Make a copy of your UI MDB, delete the linked tables, then import them (as tables rather than links) from the Data MDB. Once you enable autocorrect, Access will attempt to propagate your field name changes wherever they are used (in forms for example). Unlikely it will catch 100% of the necessary changes, but it should resolve a big chunk of them. You would then need to manually track down and fix the rest.
Once you have everything fixed, you could use that MDB version to "upsize" your tables to SQL Server. However, one huge complication is if the original database is "live" while you're making changes to the new version. If you absolutely can't take the database out of service in the interim, you could discard the data from the new tables, then use "append" queries which alias the old to new field names to pull in the latest data.
INSERT INTO NewTable (emp_id, another_field)
SELECT
[emp ID],
[another field]
FROM OldTable IN 'C:\somefolder\Data.mdb';
Finally, a warning about autocorrect: do not leave it enabled in the production version of your database because strange things can happen. The safest approach IMO is to turn it on, complete your object name changes, then turn it back off again.
You might find Rick Fisher's Find and Replace tool helpful if you need to propagate name changes through the project. I've relied on it for years (though I don't do much Access development lately): http://www.rickworld.com/products.html
I think this tool will change the names of tables and fields for you but I am not sure. I mostly used it for finding references to tables and queries in other queries, form and report properties, and VBA code.
From the documentation, I would expect adModeShareDenyWrite to be the way, but it's not working right.
I'm using an Access database via ADO. My connection string says Mode=8, which is adModeShareDenyWrite. But when I try to delete a row from a table, I get:
Unspecified error, Description:Could not delete from specified tables., Source:Microsoft JET Database Engine
In other words, the setting is preventing ME from updating the database using my OWN connection.
I found a couple other posts on the web reporting the same thing, the adModeShareDenyWrite setting used with Access not working as documented.
I am looking for a solution that doesn't involve an administrator changing permissions. It needs to be something that my program can control.
My motivation here is to minimize the chances of database corruption. One of the causes of mdb file corruption documented by Microsoft is two apps writing to the same db. So, I want to make sure that only one app can have a write connection to the db. Others can read, but should fail when they try to write. Whoever makes a connection first wins.
Cory Trager wrote:
My motivation here is to minimize the
chances of database corruption. One of
the causes of mdb file corruption
documented by Microsoft is two apps
writing to the same db. So, I want to
make sure that only one app can have a
write connection to the db. Others can
read, but should fail when they try to
write. Whoever makes a connection
first wins.
Why are you worrying about it? Jet is by default a multi-user database engine. If somebody else is updating a table, the data pages involved will be locked as read-only (in the state they were before the write began).
There is no realistic reason to fear corruption from mere multi-user interaction. Corruption of Jet databases usually happens because of dropped connections or an interruption of the connection during a write (such as users who force quit an app that is not responding as fast as they want).
I think your fear of corruption is misplaced.
On the other hand, you should still be able to open with an exclusive lock, and I'm not sure why it's not working. Have you considered using DAO instead of ADO to manipulate Jet data? Given that it's the native data interface (instead of a generic interface layer), it ought to be easier.
One solution is to give them access to a copy of the database. They can change whatever they want, but it won't keep past your copying it over with the master.
I suppose you access here an MDB file from a client interface, whatever it is, and others can also connect to the same file at the same time. When you use adModeShareDenyWrite in your connection mode, it means that you can still share the data with others (no locks of any kind on tables or records in the MDB file) but it can't be modified (this is why you get an error).
One solution would be to manage your connection parameters, with something like that:
(where you have a user object with a '.role' property, or anything equivalent ...)
if activeUser.role = "admin" then
m_connectionMode = adModeWrite
else
m_connectionMode = adModeShareDenyWrite
endif
Then you can open your ADO connection with the parameter m_connectionMode. Administrators will be given the right to insert/update/delete while other users will ony be able to view the data. This means you have somewhere in your program, or ideally in a table, some data saying who is what in your application.
EDIT: Following multiples comments with Corey:
You won't be able to do what you want to do in a straight way. My proposal: when the app accesses the database, it checks for a special file in the .mdb folder (whatever the file is).
If this file exists, the app opens a "read-only" connection.
If this file does not exist, the app creates the file (you can create one for example with "transferDatabase") and open a read-write connection. Once you quit the app, destroy the file.
If you have multiple users connecting to an access database across a network you might want to consider upgrading to SqlServer instead of using Access.
Corey Trager wrote:
I am looking for a solution that
doesn't involve an administrator
changing permissions. It needs to be
something that my program can control.
Well, if the problem is due to NTFS permissions being read-only for the user, there isn't a thing you can do to make the MDB writable. You don't specify where the MDB is stored, on a server or on a local hard drive, but in either case, for a user to have WRITE permissions on the MDB, NTFS permissions have to be set to allow it (for a share on a server, it has to be allowed both on the SHARE and on the underlying file). If it's a local file, the best solution is to make sure that you're storing the file in a location in which user-level logons have full WRITE permission. This would be anywhere in the user profile, and just about nowhere else.
That said, I'm not really suggesting that this is the source of your problem (I really can't say one way or the other), just pointing out that if it is the cause, then there's not a damned thing you can do programmatically to work around it.