Cannot Publish Access Database to Database Services
Hi all,
I have been attempting to Publish my access database to our new installation of Sharepoint 2010 and am receiving the following error:
When i view the table, i get only one error which is:
This is a fairly simple database with two tables, 3 reports, 2 forms and only one uncomplicated relationship.
Any help would be appreciated.
Thanks!
I have been attempting to Publish my access database to our new installation of Sharepoint 2010 and am receiving the following error:
One or more of the site's Queries, Tables, or Macros were recently changed and failed to compile. The site is down to prevent data issues while these objects are in an invalid state.
Click here to view the errors in Microsoft Access.
When i view the table, i get only one error which is:
Compilation of 'UserInfo' failed.
This is a fairly simple database with two tables, 3 reports, 2 forms and only one uncomplicated relationship.
Any help would be appreciated.
Thanks!
Saw one article on the web that stated they missed:
"the web form under "File"-"Options"-"Current Database".
...and they referenced this link:
http://office.microsoft.com/en-us/access-help/set-the-default-form-that-appears-when-you-open-a-database-or-web-application-HA010341995.aspx?redir=0
Have any idea what "UserInfo" is?
"the web form under "File"-"Options"-"Current Database".
...and they referenced this link:
http://office.microsoft.com/en-us/access-help/set-the-default-form-that-appears-when-you-open-a-database-or-web-application-HA010341995.aspx?redir=0
Have any idea what "UserInfo" is?
<<Have any idea what "UserInfo" is? >>
I believe it refers to the startup options, but I'm not positive.
Jim.
I believe it refers to the startup options, but I'm not positive.
Jim.
ASKER
I actually rebuilt my DB from scratch and copied and pasted the data. When i did this i custom made a new web form and set the option under "current database" to auto launch that. No luck, I am thinking that "UserInfo" may be on the Sharepoint system side, maybe how they track changes is glitching?
What if you create another similar "Simpler" db, and test that...?
<<No luck, I am thinking that "UserInfo" may be on the Sharepoint system side, maybe how they track changes is glitching? >>
Possibly. I found this:
http://kbalertz.com/983274/Microsoft-Office-Access-maintain-deleted-error-message-delete-database-table-named-Userinfo-Access.aspx
which suggests that it's a table, but it doesn't say if it's on the Access side or the SharePoint side.
Since you've already re-built the DB from scratch, I would think then it's something on the SharePoint side.
Maybe try removing it completely in SharePoint and then publish again (or under another name and see if that works).
I've played with this, but have done no real work with it yet, so this is just an educated (or un-educated?) guess.
Jim.
Possibly. I found this:
http://kbalertz.com/983274/Microsoft-Office-Access-maintain-deleted-error-message-delete-database-table-named-Userinfo-Access.aspx
which suggests that it's a table, but it doesn't say if it's on the Access side or the SharePoint side.
Since you've already re-built the DB from scratch, I would think then it's something on the SharePoint side.
Maybe try removing it completely in SharePoint and then publish again (or under another name and see if that works).
I've played with this, but have done no real work with it yet, so this is just an educated (or un-educated?) guess.
Jim.
ASKER
Attempted to publish an access database with just 1 table with 1 entry. Same error.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That did it! Running Access 2010 as a farm admin caused it to public successfully.
Thanks for your help!
Thanks for your help!
<<That did it! Running Access 2010 as a farm admin caused it to public successfully.
Thanks for your help! >>
OK, here's the deal; SharePoint has a hidden UserInfo table that's only accessible to admins. It seems like somehow the account you were using before is messed up or you didn't have sufficent priv to read that table.
So we really haven't solved this yet...
Jim.
Thanks for your help! >>
OK, here's the deal; SharePoint has a hidden UserInfo table that's only accessible to admins. It seems like somehow the account you were using before is messed up or you didn't have sufficent priv to read that table.
So we really haven't solved this yet...
Jim.
ASKER
Interesting, the account i used first was a site admin but not a farm admin. Is there any way to test access to the userinfo table?
<<Interesting, the account i used first was a site admin but not a farm admin. Is there any way to test access to the userinfo table? >>
Understand that I'm out of my league here, but I took a shot at the question because I know many are not using this yet, so you most likely were not going to get an answer.
So short answer to your question is I don't know for sure. Here's a description of the table:
http://msdn.microsoft.com/en-us/library/dd585246(v=office.11).aspx
And here's a blog about the gotcha of simple un-registering and re-registering a user:
http://cakriwut.wordpress.com/2006/08/06/change-already-added-user-information-in-sharepoint/
That blog post talks about editing the table directly, yet everything else I've seen always warns to only modify SharePoint data through the API. So I'm not sure how risky this is.
If you have an isolated test environment, then I'd try just deleting the record and then re-register the user and see if that works.
If you don't have a test environment, then I would tred very carefully. I'd first try and see if the user record can be viewed and modifed at all. Simply re-writting it may clear up the problem. I'd then go to the step of removing and re-adding the user, and see if that cleared it up.
If that all failed, then I'd set up a TEST user in SharePoint, publish a DB as that user, then delete the user record with SQL and re-add. Then see if I could still publish a DB and access the previosuly published DB. I think you'll be able to do the former, but not the latter as it looks like SharePoint uses a GUID to track users. But it also keeps the SID (Security ID), so that may still work.
As I said, I'm out of my league at this point so be carefull with trying the above.
In the meantime, I'll post an alert to see if we can get anyone with more knowledge of SharePoint.
Jim.
Understand that I'm out of my league here, but I took a shot at the question because I know many are not using this yet, so you most likely were not going to get an answer.
So short answer to your question is I don't know for sure. Here's a description of the table:
http://msdn.microsoft.com/en-us/library/dd585246(v=office.11).aspx
And here's a blog about the gotcha of simple un-registering and re-registering a user:
http://cakriwut.wordpress.com/2006/08/06/change-already-added-user-information-in-sharepoint/
That blog post talks about editing the table directly, yet everything else I've seen always warns to only modify SharePoint data through the API. So I'm not sure how risky this is.
If you have an isolated test environment, then I'd try just deleting the record and then re-register the user and see if that works.
If you don't have a test environment, then I would tred very carefully. I'd first try and see if the user record can be viewed and modifed at all. Simply re-writting it may clear up the problem. I'd then go to the step of removing and re-adding the user, and see if that cleared it up.
If that all failed, then I'd set up a TEST user in SharePoint, publish a DB as that user, then delete the user record with SQL and re-add. Then see if I could still publish a DB and access the previosuly published DB. I think you'll be able to do the former, but not the latter as it looks like SharePoint uses a GUID to track users. But it also keeps the SID (Security ID), so that may still work.
As I said, I'm out of my league at this point so be carefull with trying the above.
In the meantime, I'll post an alert to see if we can get anyone with more knowledge of SharePoint.
Jim.
Shot in the dark, but check the startup form you have specified. Make sure it's a web form and you've specified it under the web form startup.
Jim.