In a sharepoint content database we have noticed there are a couple of records in the all_docs table that reference documents that no longer exist. The listid guid that they are associated with is not in the site so we have no way to view them and delete them. I think this was a result of moving a content database from another environment into this one.
Can anyone suggest the best approach to clean this up? I need to delete it as it is referencing a page layout that I cannot delete until this page has been removed.
Have a look at Fear and loathing, it describes an undocumented stsadm command to delete an object by its id.
Related
right now I have a challenge what I'm not sure about how to solve in the best manner. I searched the internet but did not find a suitable solution ...
I want to copy data from a view on a linked server (read only; view has severals sub views and tables) to a table which is located on my database. This View contains live data, basically showing the last 100 occuring events. However, what I need is the whole history of the data shown by the view. As I have just reading permission on that specific view and the admin of the linked server is not able (or willing) to give further rights or change the view, I was wondering what the best way is to copy the view data and basically building up the whole history on my database.
I was thinking about a stored procedure and run it on a schedule, but as the last 100 events can change very quickly, this does not seem like an appropriate approach. Another option would be to build a trigger, which takes new rows an copies them to my table. However, I'm not sure if this would be possible.
I appreciate any hints, tips or impulses.
I tried using the link manager but it didn't work. I changed the names of a bunch of BE tables because they just didn't reflect their content (taking over DB from previous DBA, so it's a mess). Is there a quick way to make the FE tables link back to their BE counterparts?
There are also queries and forms that I assume I will need to edit as well.
The link manager did work but it doesn't add new tables which your renamed tables are.
So just link the new tables, and either rename the linked table names or adjust all your queries etc. to the default linked table name.
During an upgrade process from 2009 to 2016 I'm trying to remove objects relating to an old discontinued product. The objects are not within the range of or license and consists of both Forms, Tables and Reports. When deleting I'm faced with the well known error:
"You do not have permission to delete the '[object name]' Table."
I've tried with my developers license and the customers license with no luck. Since the product is no longer existing there is no use keeping these objects around and I need them gone for the upgrade process.
What is the best approach or technique when deleting objects that's not in the license?
UPDATE: How this issue was resolved?
I got in contact with the product owner and explained my problem. They sent me a neat PowerShell script to run. This worked like a charm. Reading through the script I can see that it's using the SQL cmdlets to select and delete relevant data from the following SQL tables:
Objects, Object Metadata, Object Metadata Snapshot, Object Tracking, Object Translation, Permission.
This was the preferred method of the product owner who used to develop this product. It should be applicable to all NAV objects. I have not yet successfully tried one of the answers below (more tries to come). Hopefully this new information will provide someone with enough knowledge to provide a good answer.
The way which was successfully used by several people but for sure cannot be recommended for production system is to simply delete these objects via SQL from Object and supplemental tables. In case of tables, you would need to manually delete the SQL table itself as well as its VSIFT views.
A bit more better (probably) way is to change the number of the object via SQL and then delete the object via NAV.
The best way is to use the functionality of "killer objects" - which allow to delete objects via FOB import:
http://navisionary.com/2011/11/how-to-delete-bsolete-dynamics-nav-objects/
If you find the partner who can provide you with such killer objects (they need to have a license to create objects in needed range), it solves you problem in a "clean" way.
If not, you may want to consider creating empty objects in 50000 range in some test DB, changing their number to obsolete range via SQL, exporting them as FOB, and then importing them to your target DB with "Delete" option.
Create new empty database, export only needed objects from old database, import them to new database.
In Nav 2016 application database can be separated from data containing database so (I assume) you could just unmount it from database with old objects and mount it to new application database. Not sure tbh.
It is due to the range of the license, for example your development license has a range of tables 7.000.000 - 7.000.200. If you want to delete a table with ID 20.000.000 you have that error.
The best solution is when you do the updrage do not you consider these objects you need to delete. Exports all objects except the objects you want to delete.
My users are working with a Access database which has been split into a frontend (DB.accdb) and a backend (DB_be.accdb). As they occasionally have to move the files, I've written a function to relink the tables upon startup.
Now, somehow they managed to break the file, I really don't know how. When the RefreshLink function is called for a table, there's always a run-time error (different ones, actually).
For example, error 3022:
The changes you requested to the table were not successful because they would create duplicate values in the index, primary key, or relationship. Change the data in the field or fields that contain duplicate data, remove the index, or redefine the index to permit duplicate entries and try again
I opened the frontend in exclusive mode, deleted the tables and manually relinked them. But a 1 is appended to their names: someTable --> someTable1. Seems like the tables already exist? Maybe they're still in a system table? As relinking would insert the linked table's names there, there would obviously be several tables with duplicate names.
I opened the connection manager, and indeed, it listed the old, wrong links among the new ones I just added.
I cannot refresh the old links - "duplicate values" etc.
I can refresh the new links, but of course I cannot rename the tables (removing the 1) because somehow tables with those names already exist.
I cannot delete the old tables either, as they're not displayed in the sidebar! They don't appear even if I turn on "Show system objects" etc.
I cannot remove the new links and then update the old links, as the connection manager button is greyed out then. Presumably Access thinks there are no tables.
And when I try to Compress & Repair the database, it uses the old links again...
How can I completely remove all traces of the previous links?
To recover from what appeared to be some corruption in the old front-end database file, the solution was to
create a new empty .accdb file,
import all of the Queries, Forms, etc. from the old front-end file into the new one, and then
create the proper table links in the new front-end file.
I need to find the table where community pages are saved. I found tables for blogentries, bookmarks or directories, but I couldn't find the table for communty pages? Are they even saved in the database, or are they just files on the filesystem?
The table is called Layout.
Also of relevance is LayoutSet and Group.
Web Content data on pages can be found on JournalArticle (and other tables that begin with Journal).