Highlighted
Absent Member.. Absent Member..
Absent Member..
933 views

SQL Discovery Issue

Jump to solution

Hi,
I have installed UCMDB 10.01 running on Windows Platform.
I was discovering the SQL Server and the underlying MSSQL Databases using the "MSSQL Topology by SQL" Discovery Job. Most of the SQL Servers have successfully discovered the databases.
Few of the SQL Servers they were connecting and were able to execute all the Queries which i can see from the Communication log and are showing as Success. When I try to see the discovered result CIs, i am able to see only the SQl Server and not any Database or other CIs which will get discovered from the Topology Job.
When I further checked the Log for those Servers, I was seeing an Error as follows:
Traceback (most recent call last):
File "SqlServer", line 167, in collectData
File "DatabaseProps", line 25, in getDatabases
File "DatabaseProps", line 60, in getBackup
File "DatabaseProps", line 90, in getBackupFiles
File "modeling", line 1316, in createConfigurationDocumentOSH
File "E:\hp\UCMDB\DataFlowProbe\jython\Lib\re.py", line 137, in match
return _compile(pattern, flags).match(string)
TypeError: expected str or unicode but got <type 'java.lang.String'>

Can you please check and help me to get the issue resolved.
 Some more Information :
1. These Servers have no issue with the Credentials ,they are successfully logging 
2. The Service Account also have required permissions, as I could see the SQL queries getting executed.


Regards
Ashok

Tags (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: SQL Discovery Issue

Jump to solution

I got it fixed

It seems the issue appears due the fact that the code expects the physical device name as a path but some of those are not paths so the script fails to parse it.

 

View solution in original post

0 Likes
4 Replies
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: SQL Discovery Issue

Jump to solution

I got it fixed

It seems the issue appears due the fact that the code expects the physical device name as a path but some of those are not paths so the script fails to parse it.

 

View solution in original post

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: SQL Discovery Issue

Jump to solution

I ran into this issue as well.

 

I am running on uCMDB 10.01.CUP6.438

 

 

I notice that this issue has been resolved. However, the proposed resolution is not clear to me. 


Can anyone help me out by explaining a bit more in detail on how to fix this issue?

 

regards,

Martijn Krop.

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: SQL Discovery Issue

Jump to solution
Hi Martijn,

Looks like it got resolved in CP 12.02 Content pack
The OOB script takes the "path" as the input for the Physical device name. But some Trigger CIs dont have the input as "file path", so they fails.
So you can check out the Databaseprops.py and utils.py
anyways the Latest content pack got it fixed

Regards
Ashok
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: SQL Discovery Issue

Jump to solution

Hi Ashok, 

 

Thank you very much for your reply and your solution. I will download this CP 12.02 contenpack. 

 

Last friday we found out that there is also a HP hotfix available which replaces DatabaseProps.py and Util.py.

 

We tested the replacement of these two files and this worked great.

 

http://tinyurl.com/nhrs5o8

 

Regards,

Martijn Krop.

 

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.