Video Screencast Help

Filtering Job History with job name "matches"

Created: 30 Jun 2014 • Updated: 01 Jul 2014 | 7 comments
This issue has been solved. See solution.

Every once in a while I run into a situation where I could really use a better filter than "contains" or "starts with" in job history. I note there is a "matches" option, but there is no documentation on the syntax of it, an my attempts to use it have always ended with no results and frustration. So, does anyone know how to use the "matches" option in job history filters?

Backup Exec 2012 SP4.

Operating Systems:

Comments 7 CommentsJump to latest comment

Colin Weaver's picture

Whilst I am not sure it can do it exactly what you ask (I am not right now in a position to directly check) - the Job Monitor/Job History Screen in BE 2014 along with it's filter  and sort mechanims might be a better/easier option. You could download it to evaluate and temporarily install it on a test server , run a couple of differently named jobs to disk and then see what you can filter/sort against to see if it does help.

 

Note: The BE 2014 Job Monitor/Job History screen is similar to what was presviously seen in BE 2010 and is not available in 2012

bret.miller's picture

Well, I know basically how to use Job History in 2012, and the filter for job name works with "contains" and "starts with", but also has a "matches" option. Since all my job names start with the server name, I can filter out to one server, but some servers have multiple backup sets, and there are weekly full and daily incremental backups of each set, so I was hoping to "match" both the server name and "full" in the job name to make the list smaller to wade through.

But like I said, no documentation on HOW "match" works. It's there, but if it functions at all, I can't figure it out.

As for 2014, I'm a little hesitant considering the major restructuring in 2012 where it took me a few weeks to figure out how to restructure my backup to fit with the completely new scheduling system. Plus it requires spending a while on the phone to get someone to send me the upgrade notice because for some reason I never get one even though I'm on support. But maybe I'll get that started again.

Colin Weaver's picture

Hmm well I am still not in front of a server but now you had said what the other options are I would expect the following to true

Starts with = must start with whatever you type

Contains = Whatever you type can be anywhere in the name BUT it only searches as a single string so can't be used if you have a word at the start and a word at the end but something else in between

Matches  = The whole Job name is an exact match in full for what you type in 

Have you tried testing the Matches scenario with the whole job name?

Colin Weaver's picture

Ok I did some testing in the office this morning (with 2012) and it does not work as an exact match - in fact I am not 100% sure that it does not do the same as Contains from the results I saw - which may mean we have a bug (which won't be fixed in 2012)

 

However I do have a possible answer for how to do what you want (also from my testing)

I had a repeated job history where at least two differently named jobs had run more than once each.

Format of job names was

"servername.domain.local Backup 00005-Full"

and

"servername.domain.local Backup 00007-Full"

There were also some other jobs with completely different names in my history

 

I entered

%servername% %00005%

into the Contains or Matches filter and it seemed to correctly filter on 2 split words

You could therefore try

%servername% %Full%

to see what happens

Note: the % symbol is a common IT wildcard hence we probably didn't think it needed documenting.

Note2: BE 2014 seems to also do the same for Contains and Matches

 

SOLUTION
Artegic's picture

The percent symbol is the SQL wildcard for an arbitrary string. Looks like the "Matches" filter will accept the same patterns as the SQL "LIKE" clause, see for example http://www.w3schools.com/sql/sql_wildcards.asp

Colin Weaver's picture

The internal threads I started to confiorm the behavious so far all indicate that Matches should be exact match for job name - so it looks like we do have a defect but perhaps not the one the OP would want as his request might then become an enhancement

bret.miller's picture

You're right. I didn't even think % as a wildcard. I tried the old DOS wildcards and regex, which "match" would tend to imply. Thank you!