This may be a simple fix and maybe I'm missing something obvious, but when I split my DB it wasn't entirely finished, and there have been modifications requested which require me to edit my backend.
How come it's not the same GUI layout (exactly)? Tables open in "windows" within Access, and when maximized, cannot be closed, etc. It's annoying as hell as I can't close my table to deal with its relations. I can only get to design view by finding it in the Tables list and RightClick->Design instead of on the bar above the tables, etc.
Is there a setting somewhere that caused these minor GUI changes when I split the DB? How do I put it back, as it's bugging me greatly; slowing down modifications by a lot.
EDIT: It seems that the "tab windows" option was removed for the backend for some reason..
Appearance of the windows in MS Access 2012 is controlled by the Options settings:
File->Options->Current Database under Document Windows Options
Related
Context: I'm running some simple queries in Azure Data Studio to query and manipulate data in a local instance of SQL Server 2019.
Question: When I query the table via "Select", the Run button is accessible. As soon as I Truncate the table, the Run button dims & is no longer accessible --__-- Why!? Once the button dims seems I'm unable to execute any other queries in the same query window afterwards. SMH.
Kinda ridiculous that I need to even post this question given how simple these 2 queries are. I expect this button to be easily accessible, similarly to SQL Server Management studio. I read through the docs and dont see anything about this button dimming issue. ADS is built with similar components to VSC so experience or knowledge in that tool may help. Can someone please share any tips/tricks they know on how to fix this issue?
https://learn.microsoft.com/en-us/sql/azure-data-studio/quickstart-sql-server?view=sql-server-ver15
I installed Talend last month, and no component can be deleted, as shown below:
No job is running, and this happens to all jobs. I cannot do modification at all.
How to solve this issue?
Case
The context menu in Talend is very inconsistent. By no means all actions are available there all the time. You also need to know specific menus or key commands.
Solution
Row iterators
For this case there are two approaches:
Click row1, then hit Del on your keyboard
Re-route the little black dot at the I with drag and drop to another components input and you are set.
Components
The same here, just click on it and hit Del.
NOTE: If you have further issues with the jobs, please open specific questions to those issues.
If you want to delete a component / row(connecting line between components) , please select the component/row and click on the delete button on the keyboard.
If you are unable to edit any of the jobs, then it points to an access related issue.
If you are using svn to save the jobs, it could be an svn access issue.
If you are using remote connection in an enterprise version, it could be that you no longer have access to the specific project
Is there any way to prevent start/load of DevExpress and/or Vissual assist?
Even if disabling it's up'n running the next time.
When using a limited cpu larger projects sometimes freezes everything for a bunch of minutes each time you forget to disable (and seems like I forget it each time).
Tried both out and one of them could be a nice contribute, if disabled by default.
I cannot tell you about VAssist, but automatic loading of CodeRush is controlled by the DevExpress--> Options-->Core-->Startup-->Load manually option.
I couldn't find the Startup option under Core; till I changed the Level to Expert from New User
To load it up again, you can go to Tools->Load DevExpress.
To bring up the options page, do Ctrl+Alt+Shift+O and change it to expert mode in bottom left pane.
I want to give access to all employees of the company to access the TFS server, but i just want to give them the right to view/edit and created Bugs, just Bugs, no access whatsoever to view tasks, source code or anything else, just bugs, how is this possible?
As an alternate option you could control all work item access on the Project-Area level.
TFS projects have "Areas". They can be setup to be what ever you want to call them. Many people organize these by feature or application "part".
You could restrict access to all working areas but leave access open to a "Triage" or "Bug Reporting" area. (Or if you just want to shut people out entirely just remove them from the root "Area" node.)
To do this right click on your project in Team Explorer and select Team Project Settings. From the sub menu select Areas and Iterations.
Set up your areas something like this:
Select the Development area then click the Security button in the bottom left corner.
In the resulting dialog you can setup permissions as needed to restrict view and edit access to work items in that area. Then when your developers make work items (tasks etc) make sure they set the area correctly. This will limit access to those work items.
Since you leave the "Bug Reporting" area open, users can still add bugs (or sadly Tasks) to that Area. Once you plan on working on the bug you can move it into the Development area.
This works, but has several drawbacks:
Users can't see the status of the Bug they reported once it goes into development. A Sharepoint dashboard report could help with allowing viewing of that status.
Users can still make non-bug work items. This means they can make tasks and such if they choose to.
An alternative is the use the Work Item Only View of TFS. This is a tfs portal that is setup automatically with TFS 2010 and can be installed in TFS 2008. It allows users to enter work items and see work items that they entered. But that is all. This is a fairly limited view, but it may work for you. (But remember, a person can only view work items that were created by them.)
The main benefit is that you don't have to purchase a CAL license for users to use the Work Item Only View (WIOV). Depending on how many users you are planning to give access to, that can save you a lot of money.
Here is a link about that: http://msdn.microsoft.com/en-us/library/cc668124.aspx
As a side note, both WIOV and the Area security would work fine together if you want.
EDIT: After re-reading your comment I think you might have been asking how to restrict users from accessing source. To do that open the Source Control Explorer and right click on a project or the root node and select properties. From there you select the security tab and you can deny access to source control from there.
This can be done for creation, but not viewing (to my knowledge). However, this is a lot of work. To do it you have to edit the work item type templates.
Basically you would edit the non-Bug templates so that only a specific group of people have rights to all the fields. You would also have to restrict transitions (i.e. move the non-bug work item to "Created" (or what ever your "new" work item state is).
This is a lot of editing, but it could be done.
This blog post gives the basic idea:
http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/178bc809-0035-45ee-9e0a-65ac412186f1/
and this is the docs for the Not parameter to deny transition permissions:
http://msdn.microsoft.com/en-us/library/aa337653.aspx
And lastly, here is the ValidUser docs:
http://msdn.microsoft.com/en-us/library/dd997577.aspx
We have two Application Tier servers, one is used by the client only, so I edited the JS source for TFS web access to not allow adding anything other than Bugs, Change Requests or Issues.
In (TFS Deploy folder)\Application Tier\Web Access\Web\Resources\Scripts, you can edit the DocumentService.js file:
//Opens new workitem editor with specified workitem type.
//workItemType: WorkItem type name.
DocumentService.newWorkItem = function(workItemType, tfsLocator)
{
if (JsUtility.stringIsNullOrEmpty(workItemType))
throw "Unspecified WorkItem Type Name.";
if (workItemType != 'Bug' && workItemType != 'Change Request' && workItemType != 'Issue') {
alert('Only Bugs, Change Requests and Issues can be created from this site');
}
else {
var _url = this.createUrl(CommonUrls.WorkItemEditor, { wit: workItemType }, tfsLocator);
return WindowHelpers.openWindow(_url, "_blank"); }
}
I'm currently developing a wp7 app (don't want to tell too much ;), but I'm struggling a little with the user interaction.
The main question, I'm not sure about is: Should I offer an explicit save button in dialogs and use the phone back button as cancel, or should I save implicit the time the user taps the phone back button ...
The more I think about, the more I'm unsure about the best user experience.
I already read the user experience and interaction guide from Microsoft, but there isn't any advice in there about that issue ...
Thx alot for your suggestions.
On page 68 of the Windows Phone 7 UI Design and Interaction Guide it states:
Changes to Application Settings should be immediately implemented. This means that a "Done", "OK", or other confirming dialog is not neededd. In some cases, even though the change has happened immediately, the user may not have feedback that the change has occurred until an ongoing event is completed or a future event occurs. Examples would be joining a secure Wi-Fi network or changing the frequency of alarms.
Keeping Application Settings brief and clear should be a design goal. Complex, multi-page, multi-level Application Settings can frustrate or confuse users into thinking that they have entered another application entirely.
Although the same page also goes on to say:
Immediately implement user-selected Application Settings without a confirming dialog box and provide a feedback method to indicate that the change has occurred.
Avoid creating Application Settings that have more than 2 pages (screens). Settings that require more than a single screen should use overlying half screens to avoid losing context when
the SIP Keyboard is displayed.
If a task cannot be undone, always provide the user with an option to cancel. Text entry is an example. Actions that overwrite or delete data, or are irreversable must have a “Cancel” button.
When using additional screens with commit and cancel buttons, clicking those buttons should perform the associated action and return the user to the main settings screen.
To keep the heading of settings control panels consistent, the heading for the settings page should look as follows:
SETTINGS
<CPL Name/ Application Name>
Applications that fetch data over the network must have an option to disable data usage.
So, I think you only get in to questions over explicit vs. implicit if you have multiple pages for settings, and if you do it sounds like the explicit would be the way to go with sub-pages, but implicit for the initial page.
You should use explicit saving of settings.
However, for data entered it will depend on the application and the data being entered.
It's typcial to include a save button (or equivalent) otherwise there's (probably) no way for the user to cancel out of a partially entered form. This can also cause issues if there are validation issues which would prevent the saving of the partially entered data.
It depends on the app though. There is no universal rule for this.