Showing posts with label target. Show all posts
Showing posts with label target. Show all posts

Thursday, March 22, 2012

Custom Stored Procs: Determining source table name

Hello all ...

I'm looking at writing some customized insert, update and delete stored procs for a replication target. For various reasons I would like to write a "one size fits all" custom stored proc for each of these tasks.

It looks like I can get the data values passed as parameters just fine.

I was wondering if there's a way to also pass the source schema and table name as parameters, or to determine these on the fly in my all purpose stored procs. Some replication products refer to these types of values as "tokens" that can be included in the replication data stream sent to the target.

I can adjust the source database replication publications, and article definitions, but I cannot modify the actual source database tables to include these as values in data columns. It is possible a view that contains these elements as strings might fly, but I was hoping to avoid cluttering the source database.

A handy trick or technique would be helpful!

Thanks!

DB

To answer your question, no the distribution agent does not and cannot pass the table name as a parameter. Since the custom procs are per article, it is expected the table name to be included in the proc.|||

OK, I'll work with that.

Thanks very much!

DB

Thursday, March 8, 2012

Custom fields in SSAS 2005 KPI's

Hi there,

What is the best way to get a custom field in a SSAS 2005 Cube KPI?
For example, what if the user wanted two target fields, or a budget field, or a contact person field for a KPI? (mostly static data, hard coded by the user).

Thanks.

You can use the Annotations property of KPIs (and other AS 2005 objects) to store custom information. The annotations is a property bag of name-value pairs and can contain most anything you like (including complex XML). If you set Visibility=SchemaRowset on an annotation, then the annotation will be available in the schema rowset and can be used by client applications. The down side to this approach is that off-the-shelf clients will generally ignore annotations and you'll probably need a custom client application to look for and use the annotations.

Friday, February 24, 2012

Custom columns names for custom reports?

Our application allows the customer to change the on-screen field names to his personal requirements (eg Target = 2008 Target). My customer wants his on-screen field names to be reflected the metadata view so he can write reports with his change field names. We have several customers with this application so the field names will change by customer.

How do you do this, can SQL/Server support 2 field names - the original and a preferred display option?

If we change the field names how do we ensure that existing (or future) reports from Reporting Services dynamically pick up the customers preferred field name and any existing (or inherited) reports will continue always run.Question moved to SQL Server Forum.