The naming strategy is configured on the dialect provider, but it’s only used for generating table and columns from classes and properties, i.e. it’s not used for transforming raw SQL (which is always used as-is) as used in your attribute.
BTW your SQL includes an unknown @RegionCode param, you can get it from the Request dto like:
[ValidateRequest(Condition =
"!dbExistsSync('SELECT * FROM Table WHERE Id = @Id', { dto.Id })"]
The quoted is ok, although I was hoping that you don’t have to put it in every SQL and there is a solution, but I accept it.
The dto, on the other hand, is interesting, I might still be misunderstanding something, sorry, but I already tried it and it didn’t work and it still doesn’t work now, what am I doing wrong?
[ValidateRequest(Condition = "!dbExistsSync('SELECT * FROM \"Region\" WHERE Id = @Id', { dto.Id })")]
Sorry, but last question this topic: Is the copied code correct for using named connection? (for Scriptcontext)
Where can I find a description, e.g. about dbexists arguments to set e.g. namedconnection?
i.e. you can specify the named connection to use in { namedConnection:'...' }.
There’s nothing special about dbScripts, they’re just pre-registered Script Methods which you could also register yourself to call your own C# APIs. The source code for dbScripts is at DbScripts.cs