Thanks Mark! I’ve already used a static assignment, for code group CLR_ASSEMBLIES, type Program Object Item. Using a dynamic control proc was a bit overkill.But my question was more about the formal part. Will this be a feature in the future? Or what is Thinkwise’s recommendation regarding unsigned assemblies?
This has been finished and will be in the 2024.1.12 release that is expected on March 18th, 2024. @Tim de Lang Is it possible to deliver it in a hotfix? We have several demo’s coming up.
Clear answer. That satisfies the question, thank you.Btw. The assemblies are used to execute system tasks from a Windows Gui. Tasks like (like backup, restore, but also check and create of linked servers) . This way it suppresses messages with a severity < 10.It’s an administrative tool for on premise sql server, and won’t be used with indicium.
Yes, thank you Jeroen! My custom base model still had some obsolete linked base models it self. After they were removed and generation the validations were gone.Is it an idea to create a default Thinkwise validation (for workmodels) that check when a nested base model is actually duplicate? And still, shouldn’t deprecated validations be ignored by the validator?
NVM. I found out once I’ve deleted all branches, I can set the checkbox Protected manually.
The 2nd option would be the most formal and complete approach. (Aside using guard triggers on the sf db as the ultimate protection). When it can be implemented with a dynamical control procedure, it might be less work then it looks like possibly making it more desirable.
@Robert Jan de Nie I recognize your argument and agree to a degree. To counter:If you exhaust this argument, the setting in sf_config is redundant too Sometimes you don’t have the means (time/planning, capacity or cost wise) for an extra set of eyes and the depreciation of quality is a calculated decision. Having no option, you enforce to employ extra means.I’d rather have either code review selectively per model/branch, or no option at all in case the Software Factory wants to enforce review capacity.
@Jeroen van den Belt to be clear, with parameters from the signature I meant the parameters of the prog object. create procedure def_project( @default_mode tinyint, /* 0 = add, 1 = update */ @import_mode tinyint, /* 0 = regular, 1 = import */ @cursor_from_col_id varchar(255), /* trigger column */ @cursor_to_col_id varchar(255) output, /* focus column */ /* column values */ @project_id project_id output, @project_desc description output, @finished no_yes output, @finished_date date output, @insert_user user_name output, @insert_date_time date_time output, @update_user user_name output, @update_date_time date_time output)
@Jeroen van den Belt To clarify:My idea is particular of interest in the process of creating a new template and assigning it. (or vice versa)There are two ways to accomplish that You follow the order of tabs/screens given in the software factory:Screen “Control procedures”: Create a new control procedure Screen “Templates”: Create a new control procedure template. You can’t begin coding yet, for you don’t know the parameters from the signature of the program object yet. You place some dummy code (like a comment) to be able to save the control procedure template, because it’s mandatory. Screen “Assigning”: Assign the template Screen “Deploy”: Generate Copy the signature parameters of the program object. Screen “Templates”: Open the code and paste the signature parameters Happy coding!You don’t follow the order of tabs/screens:Screen “Control procedures”: Create a new control procedure Screen “Assigning”: Assign the dummy template. A new control proc template will be generated for you. S
What about automatically assigning the validation to the one that created or mutated the related object? I think that would make much more sense.
@Robert Wijn 2 also a good idea. However, you won’t see the signature then when you open the code file in an SQL editor such as SSMS. I like to have them available in the code it self.And if you put a declare before it, you can actually use it in the code to let intellisense recognize the parameters.declare @default_mode tinyint, -- 0 = add, 1 = update @import_mode tinyint, -- 0 = regular, 1 = import row, 3 = import @cursor_from_col_id varchar(255), -- column that triggered the default @cursor_to_col_id varchar(255), --output, -- cursor in column after leaving the default @auto_commit bit, --output, -- 1 = auto commit @model_id "model_id", --output, @branch_id "branch_id", --output, @sync_target_iam_id "id", --output, @host "server_name", --output, @db_name "db_name" --output
@Robert Jan de Nie it already is, by default
to refine: I meant the default chosen value, still being able to chose to archive the branch.
So, why is branch DEVELOP not automatically protected, as stated in here?
@PeterKeeris I’m not sure a variant is a workaround, but just the solution for your requirements.I mean, sure, I think it could be done easier, but that goes for all elements you can configure for a screen. And where to draw to line then? Because if you then model all this in the context of a reference, it will basically leads you back to a what already exists, a variant.
@Jeroen van den Belt I like your proposal, since I do use the line numbers, even when I’m opening the code in another editor like SSMS. Which coincidentally also supports line numbers.
Already have an account? Login
Enter your 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.
