I have an Access database originally developed in Access 2003 or 2007 that I have inherited. This database is split as a Front-End and Back-End, and I have come across a need to programmatically re-link the back-end due to the technical competence of the people that will be handling this database.
Problem is I get an error 3044 (not a valid path) when attempting to re-link two tables, the rest re-link just fine. The error message displays the original, defunct back-end file in a directory that does not exist. I was able to gleam the cause of the issue from this thread:
"After looking through the issue, it appears the reason you are seeing a problem with these 8 specific tables is because they each have at least one memo field within them that has version history turned on (append only property set to yes). When this property is set to “yes”, it stores additional information about these linked tables within one of the system tables and for whatever reason after the table is initially linked it seems to retain this original link information about these tables."
sounds like a MS Access bug, but there you go. i set those to "no", and so far all is just fine!
This appears to match the behavior, and the solution does indeed work in a defunct version. However we would prefer to keep the option "Append Only" for our tables.
I can delete the linked tables from my front-end and add them back in, and it appears to work fine (ie not breaking anything, yet) for my personal test. Now I want to do this programmatically.
How can I programmatically handle error 3044 and delete/re-add the tables?
Look into DoCmd.TransferDatabase acLink for linking a table with VBA msdn.microsoft.com/en-us/library/office/ff196455.aspx
Related
I am new in vb.net programming. Am facing a problem in database handling. Am using oledb to deal with database, which is MS Access in my project. I am dealing with queries at the time. Now the problem is that my queries are working well on vb form but are not affecting the actual database. For example, when am adding a record, it displays 'record added successfully', the message I have used for my conformation, but the actual database is not displaying the record I just entered and even got the above conformation message as well. I have checked query in sql editor too, its doing well. I have checked locals in vb debug mode, all are containing correct values.
Am not getting what's the reason behind that. Why it is displaying the success message but not modifying the actual database. Same is the case when am firing delete query, till now. I have not tried Update query yet.
Technology - Visual Basic.net with MS Access
Am using Access 2007 and Visual Studio 2013
Please Help by your suggestions
Do the controls on your form have the correct control source, i.e. the database table/query from and to which it should be reading and writing to?
Basically the problem was the gap between my understanding and .Net's working.
Here is the solution.
You can include database in two ways:
1.Either importing it directly to your project from the place, for example using drag and drop, or some other such method.
2.Or, by including it via using wizard.
But, the difference lies in connection string you use in your project, if you give absolute path of database, then you will directly see the alterations in database you have done using your application, even in testing and debugging mode via IDE.
connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\xyz.accdb"
But if you are using connection string provide by wizard, for example,
connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\xyz.accdb"
what the IDE will be doing is whenever you will be running project for debugging or testing, every time, it will copy the actual database, with its contents as well, in /bin/Debug folder. So, the changes you are performing will only be visible to that copy, not the actual file. So, if you want to verify with the database, like in our case, check the copy of database, which will be present in /bin/Debug folder. You will see the changes there. But, every time you run project for debugging, it will replace that copy with original one.
So, actually I was checking the original database file, not that copy, since the changes were only made to that copy. So that is why I was facing the above problem, not due to any programming fault.
The view designer inside Microsoft Access ADP always adds _1 to all table names, also all table fields are not shown. The only thing that shows inside the table is *(All Columns)
I have tried access 2007 and access 2010 and both have the same output.
Every view inside the database is shown in this way, and the fields never show.
This problem is within a specific database. Other database show normally.
I am forced to make my changes inside the SQL Sever.
I found something on the Microsoft website that says if the database server driver does not have permission then the fields will not populate, but I cannot seem to find a solution.
Please help!!
I found the solution, if someone else has the same issue.
Turns out that the database name included the "." and space character, and this was the source of the problem even though everything else worked fine. Access was not finding the table fields. I renamed the database and the problem was solved.
I'm currently having a problem at work.
Someone in the is modifying the table directly.
For example in my database I have school names like ETS. Well, today it was named Polytechnique.
What I'm trying to tell who did this modification either by his/her IP address or any other way. I currently have no ideas on how to proceed.
What I would like is just the beginning of a solution as to let me figure a part of it . I sadly don't have any ideas for the moment.
Thank you (I'm sorry for any errors english is not my first language. Also I could be mistaken for the tags)
(Welcome to SO. Sorry no one answered your question yet. It almost never takes this long.)
The short answer is: No. There is no way to find out who was modifying your tables directly. Access does not have any kind of automatic change logging, and you cannot create any logging procedures in VBA that will monitor manual changes to the tables.
One of the requirements for Access as a front-end is that you trust your end-users to not open tables and edit the data directly.
To prevent this in the future, here are some options:
Right click on your table to hide it. However, the user can just unhide it if they know it is there.
In your Access db is an option called "Display Navigation Option". Disabling this will hide the side-bar so the user can't see the tables. However, pressing F11 will still display them again. This can be easily googled, so I don't recommend it if your users are motivated.
Store your data in a SQL server and use connection strings (not direct links) to retrieve and store information.
Distribute your Access db via Sharepoint. The user will only be able to access the forms you specify and will have no direct access to the tables.
Consider another software package for your problems.
I'm troubleshooting a problem with a Visual Fox Pro application (built with the Visual Fox Express framework) which I suspect is being caused by a race condition. The application is being hosted on a Citrix XenApp server and under certain conditions, data displayed on a certain form appears to be incorrect, and changes to something other than what the user is entering.
The form in question displays a list of records returned from a query on a SQL Server database based on certain information entered by the user.
If this is what is happening I suspect the sequence of events is something like this:
1) User 1 enters data and causes form to dispay grid of data of
results returned from database.
2) User 2 opens same form on different Citrix session and enters data
causing form to display a grid data of results returned from database.
This cursor gets persisted to disk and overwrites, or somehow
conflicts with User 1's cursor for that form.
3) Some FoxPro cursor mechanism on User 1's instance sees changed data
in the cursor (from User 2) and updates the screen with data from the
cursor.
I don't know much about how FoxPro works but from what I understand in some circumstances a cursor will be persisted to a temp file. On our Citrix application server this temp folder may be shared by between 10 and 50 users. I'm looking for information about if a race condition caused by a cursor written to a file in the temp folder is something that is even possible so that I can continue researching down that path or rule it out definitively.
I know there are ways to make it so that the FoxPro temp files are written to a different folder for each user and I am working on making the change to do that but I would like to find out if anyone else has seen a similar problem or thinks that what I suspect is actually possible.
IT does sound strange, but yes, Foxpro creates temp tables of cursors it uses for display and query results, such as local or remote data access. However, when created, they are created as read-only or read-write, but ONLY for the person per connection. When a cursor attempts to be created, it generates a random file name for the results and uses that as the .dbf cursor for presenting to the user.
COULD IT be a racing issue? I doubt that, but not knowing specifics of the quite old Visual FoxExpress framework, don't know what/where you would configure to have it dynamically use a different location of temp files. It should be going to the temp files path of the Windows environment variables. So, if users of the Citrix connection are using the same user / password for multiple sessions, yes, it would go to the same location, but when trying to generate the temp file, it would fail getting an exclusive handle and try again with the next random file name.
I'd say very unlikely that temp files are implicated here. Each cursor you create uses a different temp file; I don't see how two users, even in a Citrix-type situation, would share a single temp file.
So I've created an Access Project for one of my users so he can connect to a reporting database. The .adp project connects to the DB and he can query data to his heart's content. The problem is, no queries can be saved. Whenever he opens the project, he is presented with the following error:
"This version of Microsoft Access does not support design changes with the version of Microsoft Sql Server to which your Access project is connected. See the Microsoft Office Update Web site for the latest information and downloads. Your design changes will not be saved."
Again, this is Access 2007 and Sql Server 2005. My googling efforts - which are coming on a day when I seem to be especially stupid - keep bringing up information regarding this error for Access 2002/2003 trying to connect to Sql Server 2005, which is clearly not my problem.
I'm seeing that one can connect to Sql Server with the normal Access databases (.accdb in 2007 or some such), but I'm seeing mixed information regarding whether I want to do this or not. And since I can't get a copy of Access 2007, I can't really test this (topic for another time).
Before I do down that road, I'd like to get to the bottom of this one. Anyone have any suggestions, useful links, or useful knowledge? Or an older developer who knows the answer that is no longer needed, so I can eat him and absorb his knowledge and powers?
The account being used to connect to the DB was only a db_reader. I changed it to DBO and that fixed the problem - user can now create and save queries, and sleep at night knowing that tomorrow will bring a new day with new querying possibilities.
I'm not super crazy about this though the reporting database has been set up on a separate install/server from impotant App databases. I'm not worried about the user (or anyone on his group) blowing anything up. I'd like to understand why this is, and don't (outside of the obvious - reader is read only! I didn't expect that to extend to work in Access), and will try to do so at a later time. One of the unfortunate aspects of working at a dev shop focused on internal app development is, "well, it's working, you have other things to see to".
I am not sure if I can be of help here.
But you can have a view inside Access which connects to SQL database and use that view.
Alternatively, you can go the other way. Have a DB project with SQL Server & create a linked server to MS-Access DB.
Did you try linking to the tables through an ODBC connection?
CodeSlave, I did not. The attitude from higher up is "it's working, move on". I'm not sure the boss really wanted to go down that road anyway, but it's a moot point. I should probably try granting the account dbreader and dbwriter access and see if that accomplishes the same thing, but it being dbo isn't really a huge deal. Or rather, it's not a big enough deal that The Powers That Be want me to seek an immediate change.
I was going to try linked tables until changing the SQl Server account permissions "fixed the problem" (quotes very deliberate; it feels like one of those solutions you arrive at without a proper understanding of what it worked, which vexes me).