Showing posts with label together. Show all posts
Showing posts with label together. Show all posts

Saturday, February 25, 2012

Matching a Views columns to its underlying tables columns

Hello,

Using SQL Server 2000, I'm trying to put together a query that will
tell me the following information about a view:
The View Name
The names of the View's columns
The names of the source tables used in the view
The names of the columns that are used from the source tables

Borrowing code from the VIEW_COLUMN_USAGE view, I've got the code
below, which gives me the View Name, Source Table Name, and Source
Column Name. And I can easily enough get the View columns from the
syscolumns table. The problem is that I haven't figured out how to
link a source column name to a view column name. Any help would be
appreciated.

Gary

select
v_obj.name as ViewName,
t_obj.name as SourceTable,
t_col.name as SourceColumn
from
sysobjects t_obj,
sysobjects v_obj,
sysdepends dep,
syscolumns t_col
where
v_obj.xtype = 'V'
and dep.id = v_obj.id
and dep.depid = t_obj.id
and t_obj.id = t_col.id
and dep.depnumber = t_col.colid
order by
v_obj.name,
t_obj.name,
t_col.namegaryderousse@.yahoo.com (Gary DeRousse) wrote in message news:<9ce1cc62.0311051041.2dd0f428@.posting.google.com>...
> Hello,
> Using SQL Server 2000, I'm trying to put together a query that will
> tell me the following information about a view:
> The View Name
> The names of the View's columns
> The names of the source tables used in the view
> The names of the columns that are used from the source tables
> Borrowing code from the VIEW_COLUMN_USAGE view, I've got the code
> below, which gives me the View Name, Source Table Name, and Source
> Column Name. And I can easily enough get the View columns from the
> syscolumns table. The problem is that I haven't figured out how to
> link a source column name to a view column name. Any help would be
> appreciated.
> Gary
>
> select
> v_obj.name as ViewName,
> t_obj.name as SourceTable,
> t_col.name as SourceColumn
> from
> sysobjects t_obj,
> sysobjects v_obj,
> sysdepends dep,
> syscolumns t_col
> where
> v_obj.xtype = 'V'
> and dep.id = v_obj.id
> and dep.depid = t_obj.id
> and t_obj.id = t_col.id
> and dep.depnumber = t_col.colid
> order by
> v_obj.name,
> t_obj.name,
> t_col.name

I don't believe that this information is available - sysdepends
records that the dependency exists, but not exactly what the
dependency is. The mapping of view to table columns could be 1:N or
M:N (or 1:0, in fact), so I would guess that MS decided that it wasn't
worth the effort to try and capture the detailed column mapping.

Simon|||Simon,

Thanks for the information, even though it wasn't what I wanted to hear.

Gary

sql@.hayes.ch (Simon Hayes) wrote in message news:<60cd0137.0311060041.35542cec@.posting.google.com>...
> garyderousse@.yahoo.com (Gary DeRousse) wrote in message news:<9ce1cc62.0311051041.2dd0f428@.posting.google.com>...
> > Hello,
> > Using SQL Server 2000, I'm trying to put together a query that will
> > tell me the following information about a view:
> > The View Name
> > The names of the View's columns
> > The names of the source tables used in the view
> > The names of the columns that are used from the source tables
> > Borrowing code from the VIEW_COLUMN_USAGE view, I've got the code
> > below, which gives me the View Name, Source Table Name, and Source
> > Column Name. And I can easily enough get the View columns from the
> > syscolumns table. The problem is that I haven't figured out how to
> > link a source column name to a view column name. Any help would be
> > appreciated.
> > Gary
> > select
> > v_obj.name as ViewName,
> > t_obj.name as SourceTable,
> > t_col.name as SourceColumn
> > from
> > sysobjects t_obj,
> > sysobjects v_obj,
> > sysdepends dep,
> > syscolumns t_col
> > where
> > v_obj.xtype = 'V'
> > and dep.id = v_obj.id
> > and dep.depid = t_obj.id
> > and t_obj.id = t_col.id
> > and dep.depnumber = t_col.colid
> > order by
> > v_obj.name,
> > t_obj.name,
> > t_col.name
> I don't believe that this information is available - sysdepends
> records that the dependency exists, but not exactly what the
> dependency is. The mapping of view to table columns could be 1:N or
> M:N (or 1:0, in fact), so I would guess that MS decided that it wasn't
> worth the effort to try and capture the detailed column mapping.
> Simon

Monday, February 20, 2012

Master->Detail Reporting

I'd like to put together a summary report for some of my management staff. The report should show the # of jobs that match about 20 different statuses. Each status has different criteria. For example, one might look for a date in a datetime field and the type of job. Another might look at whether a date has passed and the quantity we're shipping.

Sort of like this:
Status Items Jobs
Status #1: 50000 15
Status #2: 25251 3

I want the user to see this summary information, but also have drill down capability. I'd like the ability to print the summary or just a drill-down.

I'm also considering using Dundas Charts for RS on the report.

Can I accomplish this with Reporting Services? If so, any tips on how to do it? If this a bunch of sub-reports? Can I sum the # of jobs on a sub-report? Should I be looking at BI for this?

Or should I be working on a Forms-based?

Thanks!
Brian

bes7252 wrote:


I'm also considering using Dundas Charts for RS on the report.

Why would you need a chart for this? Basically you would use either a table or matrix for this.

bes7252 wrote:


Can I accomplish this with Reporting Services? If so, any tips on how to do it? If this a bunch of sub-reports?

Yes, you can accomplish this with RS. You need to craft the proper SQL query that will give you the data you need for the table. If you get stuck, there are many SQL pros here that can help you. This doesn't have to be a bunch of sub-reports. It could be as little as two -- one to drilldown on the Item field and one to drilldown on the Jobs field.

Tips:

1. Create the parent report and get the data for the report that you need using a SQL query.

2. Create the subreport layout and pass parameters as needed from the parent report to subreport.

bes7252 wrote:

Can I sum the # of jobs on a sub-report? Should I be looking at BI for this?

1. Yes

2. If you want to, but it isn't necessary.

You will find that the power of these reports is SQL. If you aren't comfortable with SQL, you probably won't be very comfortable doing this.

|||> Why would you need a chart for this? Basically you would use either a table or matrix for this.

I should have used the word Gague instead of Chart. The report is sort of a dashboard look at a section of our business. I figured if I wanted to provide more info for each status (like avg jobs/day over the last 2 weeks) then a gague might provide a nice visual.

I am comfortable with SQL, but an not familiar with all the ways to use MSSQL. It seems like every time I figure out a way to do something, someone shows me a better way. I think you're suggesting I create the columns in the SELECT statement like this:

SELECT (SELECT COUNT(*) AS EXPR1
FROM Person.Contact
WHERE (EmailPromotion = '1') AND (LastName > 'S')) AS col1,
(SELECT COUNT(*) AS EXPR1
FROM Person.Contact AS Contact_1
WHERE (EmailPromotion = '0') AND (LastName <= 'S')) AS col2

Assuming I've done this correctly, I have a concern. One of the reasons I considered a sub-reports is then I know the data from each subreport will match the total on the parent. If I use a WHERE condition (like shown above), can I make sure the drill-down data always uses the same condition? Maybe store it in a variable? I'm concerned that down the road we'll change the condition in the parent, but forget to change the detailed view.

Brian
|||

bes7252 wrote:

> If I use a WHERE condition (like shown above), can I make sure the drill-down data always uses the same condition? Maybe store it in a variable? I'm concerned that down the road we'll change the condition in the parent, but forget to change the detailed view.

Brian

The where condition shown above is what we call a 'hard-coded' value. You would want to create parameters in place of those values. In reporting services, we typically use parameters (similar to variables).

It would be something like WHERE EmailPromotion = @.emailPromotion AND LastName <= @.lastName.

When I use parameters, I like to put them in a stored procedure (as opposed to a text query).

The final step to this (once you get a stored procedure working in the parent report with parameters) is to pass the values by right clicking on the chart -> properties -> navigation. Here you can pass the parameters to the drill down.

In the drill down you would use a similar approach:

WHERE EmailPromotion = @.emailPromotion AND LastName <= @.lastName

Therefore, it would get the passed parameters from the parent report. Then the values are not "hard-coded".

|||

Greg,

That makes sense. Can I define the entire Where clause as a parameter? Then pass it in to the stored procedure and have the SQL built on the fly?

(This one might be outside the scope of this forum.) I'll probably use a ReportViewer control embedded in a WPF application. Once the user drills down he'll see job numbers. When the user clicks on a job #, can I have launch a form? Perhaps this would involve some kind of event binding between my code and the ReportViewer control?

Brian

|||

bes7252 wrote:

Can I define the entire Where clause as a parameter? Then pass it in to the stored procedure and have the SQL built on the fly?

I would just use the parameters that I indicated with @. signs as parameters. I wouldn't pass the entire where clause as a parameter.

bes7252 wrote:

When the user clicks on a job #, can I have launch a form? Perhaps this would involve some kind of event binding between my code and the ReportViewer control?

I use Visual Studio to handle all of the event binding. Do you have Visual Studio 2005 or just SQL 2005? Visual Studio handles this quite well.

|||

>> I would just use the parameters that I indicated with @. signs as parameters. I wouldn't pass the entire where clause as a parameter.

Will I suffer performance loss if I do this? I ask because the WHERE clause for each status will be drastically different. I'd prefer to guarentee the parent always matches the child by storing the entire string in a parameter.

>> I use Visual Studio to handle all of the event binding. Do you have Visual Studio 2005 or just SQL 2005? Visual Studio handles this quite well.

I have VS2005 Pro. The app uses WPF for the interface, but the ReportViewer is inside a Winform control. (I can't remeber what it's called). I'll look through the event bindings.

Thanks much for your help.

Brian