SSGREP

SSGREP is a tool for searching files in your version-control repository. While your version-control system may or may not offer a search facility, SSGREP is likely to be more powerful, since it gives you the full power of Perl's regular expressions. Furthermore, by default, SSGREP strips all comments from the code when searching for known file types, so that you only get matches from program code.
SSGREP can produce the output as plain text, HTML or save it to a database.

To specify which files SSGREP is to search you must specify one of ‑config or
‑VC. Use ‑VC when you want to search a single VC-path.
If you want to search multiple paths, use a
config-file with the ‑config option. No matter
which option you use, SSGPEP always searches the most recently checked-in
version of each file. Thus any explicit label in the config-file is ignored.

SSGREP ignores these files:

Files that are binary according to the version-control repository

Files in directories where the path includes SQL/scripts. (Because this directory would give you lots of hits in scripts
that are not likely to be relevant.)

You can use the options ‑type and ‑lang to restrict SSGREP to
only search certain
files. Both these options can appear multiple times on the command line. With
‑type you specify a file extension, with or with out the leading period. For
instance, ‑type .sp ‑type TRI instructs SSGREP to only
search stored procedure and trigger files.
‑lang is a shortcut to ‑type that permits you to
specify all types for a certain programming language in one go. The following
values are recognised:SQL – The SQL files according to the
AbaPerls SQL directory structure.
VB – Files of the types .bas, .cls, .frm
and .vb.
C – Files of the types .c, .cs, .cpp, .h
and .hpp.

The search patterns for SSGREP are regular expressions according to the rules
of Perl. The manual page for SSREPLACE includes
a crash-course in regular expressions.
Note that you cannot search for matches that span multiple lines, as SSGREP
match each line separately against the search pattern.

If you supply multiple search strings, SSGREP joins them to a single regular
expression with the | (OR) operator. That is:

SSGREP -VC $/MyProject this_string that_string yet_another_string

is the same as

SSGREP -VC $/MyProject "this_string|that_string|yet_another_string"

Tip: if you want to search for a string and only want to get hits on
whole words only, embed the string in \b. That is, if you say

SSGREP -VC $/MyProject trip

This will list lines that include words like strip or tripping,
whereas

SSGREP -VC $/MyProject \btrip\b

will only list matches with trip as such.

You can specify the input in three different ways. Most of the time you will
use the command line, but if you have very many search strings, or you have
problems with characters that are special to the DOS command line you can
specify an input file with the ‑input option. In the file you can specify
multiple search patters and SSGREP will join them with the | operator
to a singular regular expression. SSGREP strips
leading and trailing speces from the lines and ignores blank lines. There is no
provison for comments in the file.

The third way to specify is the ‑resume option, which you only can use when you also
specify the ‑database option. See further below about
using a database.

There are two options to control how SSGREP performs the search. By default,
SSGREP performs a case-insensitive search after having stripped all comments
from the files. More precisely, SSGREP strips comments from files of which
AbaPerls understands the format. These are the same file types as those listed
for the ‑lang option above.

That is, beside the matching line, SSGREP also prints the line before and after the match. The line with the match is highlighted. If you specify
‑window 0, SSGREP only prints the name of the
matching files, but does not print the lines.

The search pattern matches two different tables, and there is one section per
table.

If there is more than one match on the same line, the line is included the
sections for both matches.

‑crossref is very practical when you want to see which files that calls a
certain set of stored procedures. Not the least does this permit you to see
whether a procedure is used at all. Preferrably, you should include the path
where the procedure is stored. If you only get a hit for that file, the
procedure may not be in use. If you get no hit at all – in which case there is
no section – maybe you did not spell the name correctly?

Note: a better database alternative may be VCDBLOAD which loads the source
code into fulltext-indexed SQL Server database.

A third output option is to direct the output to a database. This is useful
if you are searching for very many search strings and you are searching very
many files. For instance, you could search your entire version-control
repository for all your stored procedure to get a complete cross-reference for
which you then can search for specifics. A special advantage is that when you
use a database as output, you can resume an interrupted search.

To direct output to a database, you specify the ‑database option, and
optionally you can also specify ‑Server, ‑User and ‑Password. This applies:

If the database does not exist, SSGREP creates it. For details on
tables, see below.

If you don't specify ‑Server, SSGREP assumes the default instance on the
local machine.

The first two are mainly intended to support the ‑resume option (see below),
but you can use them to review the settings for the search. Note that in
ssgrep.pattern, you will see the resulting regular expressions where SSGREP
has join all search expressions with the | operator.

ssgrep.files lists all searched files and defines an id for each file.
ssgrep.matches gives you quick references for which files that had which
matches. Or which procedures that matched in which files if yoiu like. These two
tables should be self-explanatory. Note that the collation for matchstring
is binary, so aggregations will be case-sensitive.

ssgrep.matchlines has the actual lines that matched. linenum is the
line number and linetext is the contents of that line. hasmatch is 1 if there is
a match on that line, and 0 if the line is only a context line. The latter can
only occur if you specified ‑window with a value
> 1. If you specify
‑window 0, ssgrep.matchlines will be empty.
There will still be data in ssgrep.matches.

By using the ‑resume option, you can resume a search that was interrupted.
‑resume also permits you supplement a search if you forgot to include some
directory in the first round. You can only specify ‑resume with ‑database. When you
specify ‑resume, the database must exist, and all five tables in the ssgrep
schema must exist.

When you use ‑resume, SSGREP reads the search strings from the database, and
thus it is not legal to specify ‑input or search patterns as arguments with
‑resume. SSGREP also reads the settings for ‑noignorecase and ‑comments from the
database and ignores what you specified on the command line.

SSGREP checks in ssgrep.files whether a file already has been processed, and
in such case this skips the file.