When the subject was changed (prefilters added, columns added, column order changed etc.). The way the screen was intended to be used can be changed as well. In this case the user preferences should be rebooted to default settings. The user is not always aware of a screen changing.To make this more user friendly it would be great if when a new project version is activated a popup will be shown on changed subjects after first opening the subject. The popup would give a message indication the subject was changed and it is advised to reset the screen to the default settings. This has 2 advantages: it gives the user a notification the screen was changed, and it gives the user the option to reset after a change to the screen.
When creating a context, default, layout or a template for a view you have to do the same steps. create a control procedure generate the code group search the task/view/subject in assigning assign the template8 out of 10 times this can be automated if you add only 1 template and use the standard naming standards for templates and control procedures. I would suggest adding several tasks:on tasks: a task to create the template and assign it to the task on subjects: a task to create the ctx/def/layout (checkboxes which you want to create) and assign it to the subject on data model (view): a task to create the template and assign it to the view when the view is template based. All would follow standard naming protocols.Also the tasks should check if there is already a template. Optional: use a process flow to open the just created template so you can start coding.
When an application has a lot of triggers, nested procedures or tasks within tasks troubleshooting can become rather tricky. Luckily SQL provides some tools for this, namely the profiler and extended eventes. However, it is still rather time consuming to figure out which triggers and procedures are running during execution of a task or update statement. I know there is already the template naming in the procedures, however this does not give you the task name or the type of object it is and therefor is not very useful during troubleshooting a task that gives an error. Therefor it would be very helpful to add the stored procedure or trigger name directly after set nocount on and also show the type (trigger or stored procedure). something like this: -- Do not count affected rows for performance set nocount on -- type: trigger -- name: player_position_td Then during troubleshooting you can capture all nocount on events, "set nocount on" and comments directly afterwards can be
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.