Welcome to SqlServer.Rules Discussions!

[tcartwright]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[dedmedved]

Hi Tim,

• I've linked to your SQLRules project from my own - https://github.com/dedmedved/cheburashka/wiki
• I've a number of rules still in (re)-development, plus more in planning, but have had to take a break in recent months.
• As the wiki says - I started the project many years agao, and it's gone in fits and starts ever since, depending on my time and enthusiasm.
• I'm certainly going to test your rule-set - you have a few I've only sketched out so far.
• I'm not sure that some of the rules I have, have any validity in the real world.
• I'm interested in your command-line rule executor, might kill off my own that's only just started dev.
• As regards licensing - is there anything to prevent me using the code in a commercial environment ?

PS Ded Medved is a pseudonym.

[tcartwright]

Sounds fantastic. No, there is no reason you cant edit / use this commercially. Its MIT, so have at it. If you want we could take a look at collaborating / combining. I am in the same boat, The time I can dedicate to this is limited so I tend to work on it fits and spurts as well.

[dedmedved]

Hi Tim -

I've given your ruleset a test flight over my team's current work project and found a heap of useful issues. I particularly like the inconsistent data types rule. It's given me a bunch of tasks to put into our backlog.

I'm not sure if this is the best place to raise possible issues with your rule-set but I've got the following questions/possible issues -

• The code used to look for variable occurrences uses a lower-case name comparison. This won't work for SSDT Models using a CASE sensitive collation where @AB and @ab are, as far as I know, different variables. This could be addressed by another rule insisting on case and collation insensitive identifier names ( which I think is or was something Oracle did/does)

• Warning SRD0039 : Rules : Use fully qualified object names in SELECT, UPDATE, DELETE, MERGE and EXECUTE statements. [schema].[name].
  This wrongly picks up cte names and treats them as schema objects
  eg with cte_get_counts as (…………) select ......... FROM cte_get_counts c

• Warning SRD0043 : Rules : The arguments of the function 'ISNULL' are not of the same datatype.
  ISNULL(@count,0)
  @count is an int and I guess the literal 0 is derived to be a tinyint or something - I'm not sure that this is something that is actually a datatype mismatch, or if it is then whether or not its significant.

• Warning SRP0016 : Rules : Data types on both sides of an equality check should be the same in the where clause. (Sargable)
  AND is_current_row = 'Y'
  [is_current_row] is defined as a CHAR (1)
  I'm not sure what the issue is here. - I didn't look over the implementation of the rule, but I thought I'd mention it.

Many thanks.

[tcartwright]

I am finally getting some time to investigate the issues you reported. Hopefully will not take me long to figure out. TY!

[Fortunoxx]

I'm also still interested in something like this, especially to find out data type inconsistencies. I'll probably head over to the suggestions page to leave my thoughts.

[Fortunoxx]

Hi Tim,

is this working with Visual Studio 2022? Do you happen to know the right paths for the extensions?

[tcartwright]

I don't know yet, but I will find out.

[Fortunoxx]

Hi Tim, is there any news on that? Cheers