This FAQ mentions that "Snowsight worksheets in the new web interface are stored elsewhere and are not prone to accidental deletion", so I guess it means Snowsight worksheets of dropped users can be retrieved without having to go through the history of queries as the Classic UI requires? Could someone help me with the steps or a link to the documentation for this?
Related
I am the lead developer on a project for a 'difficult' client. I will try not to bore anybody with the details but here is my issue I am facing.
Our client has a team of QA testers that are managing their project through JIRA. We currently have a fixed bid contract with them to supply them the software they requested at a fixed price and any additional features or pre-existing issues will be covered under time and materials.
They have taken the time to raise every defect within the system unrelated to the current fixed bid process and have tried to get them resolved for free and each time we have come to an agreement through JIRA comments that this is a preexisting issue/new feature and you will have to pay for it after the project has been completed which they have agreed to.
The issue is this client has a history of forgetting conversations and email trains that don't benefit them putting a lot of wasted time on our side digging up proof we agreed to handle a situation a specific way.
The project will not complete for several more weeks but as soon as it does I will likely be removed from the JIRA project by their administrator and they will begin asking again for us to complete all this additional work at no cost and I will lose access to the comments on each issue explaining to them it will not be free and them agreeing.
I am currently exporting each ticket after it closes but this is wasting about 30-40 minutes a day and would be interested if there is a tool out there that can export an entire JIRA project to a readable text format that I can run once near the project end.
TL:DR; Is there a tool that will allow me to export an entire JIRA project in a text readable format before I lose access to the project and all information included within that project
Export as CSV doesn't include comments and is limited to 1000 issues be default.
I have used the jira-python library to retrieve all issues, all fields, all comments from a single project. Missed the attachments though.
But what you have is a people problem more than a technical problem. Good luck!
Large exports (e.g. many hundreds of issues) are not recommended.
To change the number of issues that are exported, change the value of the tempMax parameter in the URL.
To export search results to Microsoft Excel:
Choose Issues > Search for Issues.
Refine your search, as described in Searching for Issues, then choose the Export menu.
Choose one of the following from the dropdown menu:
'Excel (All fields)'— this will create a spreadsheet column for every issue field (excluding comments).
Note: This will only show the custom fields that are available for all of the issues in the search results. For example, if a field is only available for one project and multiple projects are in the search results then that field will not appear in the Excel document. The same goes for fields that are only available for certain issue types.
'Excel (Current fields)' — this will create a spreadsheet column for the issue fields that are currently displayed in your Issue Navigator.
A file called - .xls will be created. Edit this file using Microsoft Excel and/or save it as required.
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.
I have an access database that has been used for many years, converted from Access 2000 to 2007 and was fine. In the last couple weeks it has been doing strange things!
There is a form for 'editing' a record. When the user clicked on the button to open this form, a small white box appeared and said 'Record Deleted'.
After that, the database was corrupted. I support this database and I can not even get into it in design view. When I try to open it (holding the shift key down while opening it), it takes a while, then it displays the Access design page that has the 'blank database' icon and to the right it lists the frequent opened databases.
So, I can't even get the to objects. The only option I had was to restore from a previous night backup. This meant the users lost all their work for the day. Today, one week later, it has happened again. All the users work was lost because I had to restore from backup.
I don't know where to begin to trouble shoot this since I can not get into it in design view when it has become corrupted. Looking for any suggestions to debug this. I can use a copy of the database I had restored.
Thanks
As a first and most important suggestion. You should split your database.You can do this from the database tools tab on top. By doing this you will have a seperate back end independat of the front end and your client will not loose any data as if they get the error / corrupted database it would not affect the data secured in the backend
Second I havent had the exact same error but in the past I have faced instances where the forms just dont work. a recommendation i read somewhere was to create a new blank form and copy over the elements from this form onto that and delete this form. I doubt if there is any problem with the VBA but it would be worth compiling the code to check.
Apologies if this does not help much, but I hope the first suggestions helps protect your client data in the instance your database crashes.
First, check if any automated VBA code or macro is running on OnOpen, OnLoad, OnCurrent, AfterUpdate, OnDirty, etc. events of the troubleshooting forms. Simply open the VBA window and look at code on the specific form's module. Or in the case of macros, open form in design view and check the Event tab of Property Sheet (and the same for specific buttons, textboxes, etc.). There may be DoCmd.RunCommands occurring when users interact with form controls.
Also, if you find yourself unable to open forms or deal with a corrupted database, consider beginning with a blank Access .accdb file and import all objects from the previous Access 2000 .mdb file. And if specific controls don't function properly, recreate them as needed.
As mentioned above, split your database between BackEnd (only tables) and FrontEnd (forms, queries, macros, modules) which prevents corruption, efficiently runs systems as only data is sent across the network and not whole application items, and overall fosters a better multi-user environment. Each user can have copies of the FE on their local machines but all will connect to one BE on a shared network. To help, Access 2007-2013 has a button for this on the Ribbon under Database Tools.
I am enhancing and fixing the forms/queries/VBcode etc. for an access 2007 database. The current version is being actively used and when I am done with my changes I need to transfer in my changes without disrupting the data stored in the tables already in the running mdb.
I'm not entirely sure how to handle the "merge" when the time comes. As an experiment I have a local backup copy of the version I started working on and used the import external Access data option. This imported the new forms, queries, vb, etc. But the only hang up is that the switchboard form isn't the new. Switchboard forms of course are guided by the switchboard manager but I was hoping that all that logic is held inside the form itself somehow. It seems this is not the case. After the import there is a new form of the same name with a number after it as expected, and the correct create/modify date. But when open it looks exactly the same as the old switchboard.
Any ideas?
It sounds to me as if you have both the data and the forms etc in the one database. This is not a good idea at all and if you are updating, it is the ideal time to correct the problem. If you split the database, any updates to forms and code can be simply copied to the user without worrying about the data. You will find some notes here: http://office.microsoft.com/en-us/access-help/split-an-access-database-HA010342026.aspx
The Access switchboard manager uses a table named Switchboard Items to dynamically populate switchboard form pages. You will need to transfer the updated version of that table to make your revised switchboard pages available in the other project.
I'm kind of new to Access. I've got some experience working with integrating MySQL and Oracle with PHP to create web-based database search engines, but I am having difficulty understanding certain concepts with Access.
I've got a small database with around 200 entries with 20 fields each. I've written a form to search it by using VBA to run an SQL query against the database and displays the results in datasheet mode to a different form (is this the standard way of doing this, or is there a better way?)
I want to be able to add a button to export those results to excel (or csv or tab or whatever, it doesn't really matter). However, I'm not sure how to do this with the form results. Its easy with an entire database, but I can't find documentation on how to do this. Is there a way to do this? Or am I doing this wrong?
If at all required, I can provide more details.
You said "I've written a form to search it by using VBA to run an SQL query against the database and displays the results in datasheet mode to a different form".
If you mean an actual form in datasheet view, you can export that form's data to Excel with the DoCmd.OutputTo method.
DoCmd.OutputTo acOutputForm, "frmResults", acFormatXLS, _
"C:\SomeFolder\ExportedResults.xls"
However, if you're opening a query in datasheet view, rather than an actual form, you can export the query's result set.
DoCmd.OutputTo acOutputQuery, "qryResults", acFormatXLS, _
"C:\SomeFolder\ExportedResults.xls"
You can choose a different OutputFormat instead of Excel if you wish. Look at Access' Help topic for the OutputTo method to see the available choices.