This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

NPM tables contents

FormerMember
FormerMember

Hi,

How can I get a listing of the database tables contents? I am not able to create the reports that my boss wants to see, so I will use a thrid party software reporting package to develop the reports this guy wants to see.

I can see the tables, and views, but I don't know where the specific data is stored to pull it for our custom reports.

Can you provide me with the tables layout?

Thanks,

Jim

  • I use Microsoft sql management studio. it will let you explore the database, that's how I create my reports

  • what particular custom report you want to create? then i will point you to what table you need to take a look.

  • FormerMember
    0 FormerMember

    After talking to others who work with databases, they suggested that I ask for the data definition file. Which is what I actually did ask for, the layout of all the tables or the properties and the data that is stored in each table.

    Would that be possible?

  • I am not sure this is want you are looking for but I have been planning to move away from reporting from the DB as it's consistently under change. For example in the most recent version of Core 2015.1 the sacred Nodes table is deprecated and split out into several new tables while the performance data tables for detail, hourly, daily, monthly is now broken up by date/time. This would require all new logic in your reporting engine, possibly up to rewriting all your reports.

    Instead I have been slowly switching over to the SDK and using SWIS/SWQL to pull out the data I want - even if it's to put into temp tables for reporting. As the SDK doc states a huge value is:

    Insulation from Database Schema Changes

    SWIS ultimately satisfies most queries by fetching data from the database, but the mapping between SWIS entities and the underlying database tables allows SolarWinds to evolve the database schema while providing a consistent, backward-compatible object model to SWIS clients.

    You also will have much fewer joins as SWIS incorporates both navigation (precreated joins you don't need to do) and also view like representation of data. While some higher level SQL functions are not available you'll find much simpler queries for an equal dataset from t-SQL. And you can always do the non-supported functions in your temp tables or reporting queries.

    Best of all- you do get the schema documentation -

    C:\Program Files (x86)\SolarWinds\Orion SDK\Schema\3.0\index.html

    Screen Shot 2015-02-16 at 9.08.05 PM.png

    Screen Shot 2015-02-16 at 9.07.57 PM.png

  • I second what said.  Insulate yourself from changes by using SWQL.  Nothing like the heartbreaking feeling of seeing your precious SQL query stop working after you've spent countless hours getting it just the way you want it--and all you've done was upgraded NPM.