OOP Objects and SSRS ? Doable? Reusable? Performance?

Is there any way to reuse Objects that returns a collection to my
report in SSRS?
Is it practical? Will it perform okay if I need to join the output
from that object with other data? Say I have a vb.net object that
already has all the business logic that joins a bunch of objects
(tables really). It's in one place and we like it that way. If I want
to use SSRS will I have to code a select (or a create a view) to get
my same expected row set?
Thanks for any help or information.You have several options. None of them great as far as I am concerned.
One is to use the reportviewer control that ships with VS 2005 and VS 2008.
Use it in local mode. In local mode you give it a dataset and a report.
However, there is a lot more coding and complexity involved and you lose the
server capabilities (subscriptions, performance, etc).
Two, to write a data processing extension. Non-trivial but possible. I would
read up on that in books online.
Or, have a web service that you query and get the data back from it. That
will work as well.
RS is not architected to perform this type of integration easily. It is a
SOA (service oriented architecture).
Crystal reports might work better if this is a hard and fast requirement.
But, do look up data processing extension. That is the best bet for you.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<wildman@.noclient.net> wrote in message
news:0802c9d7-98bb-4875-8f15-c24782d51cdd@.x35g2000hsb.googlegroups.com...
> Is there any way to reuse Objects that returns a collection to my
> report in SSRS?
> Is it practical? Will it perform okay if I need to join the output
> from that object with other data? Say I have a vb.net object that
> already has all the business logic that joins a bunch of objects
> (tables really). It's in one place and we like it that way. If I want
> to use SSRS will I have to code a select (or a create a view) to get
> my same expected row set?
> Thanks for any help or information.|||If the collections returned by your objects are 'flat' (have no nested
objects), you should be able to report on them, by exposing them as a web
service. See http://technet.microsoft.com/en-us/library/aa964129.aspx.
The documentation is a little sketchy. It works if your objects returns just
a list of fields. If there are nested objects, its not so simple.
<wildman@.noclient.net> wrote in message
news:0802c9d7-98bb-4875-8f15-c24782d51cdd@.x35g2000hsb.googlegroups.com...
> Is there any way to reuse Objects that returns a collection to my
> report in SSRS?
> Is it practical? Will it perform okay if I need to join the output
> from that object with other data? Say I have a vb.net object that
> already has all the business logic that joins a bunch of objects
> (tables really). It's in one place and we like it that way. If I want
> to use SSRS will I have to code a select (or a create a view) to get
> my same expected row set?
> Thanks for any help or information.

OO storage? How to store large graphs and enable efficient graph operations?

Storing large graph in relational form doesn't allow us to perform graph operations such as shortest path quite efficiently. I'm wondering if storing the graph as objects would be better? How should I design the schema? Thanks!There is an entire chapter (ch.9) dedicated to graphs, hierachies, etc. in Itzik's book. Highly recommend it.

http://www.amazon.com/Inside-Microsoft-SQL-Server-2005/dp/0735623139/ref=pd_sim_b_2/002-5855731-9288849?ie=UTF8&qid=1172821634&sr=8-4|||THanks, oj. But ch 9 is Transactions. Is that what you meant?|||No. Chapter 9 is about graphs, trees, hierachies, and recursive queries. Did I post the wrong url for T-SQL Querying book?|||this is what I found of this book:

Inside Microsoft SQL Server 2005: T-SQL

Programming

byItzik Ben-Gan,

Dejan SarkaandRoger Wolter

Microsoft Press

2006 (532 pages)

ISBN:0735621977

Written by a T-SQL guru, this thorough, hands-on

reference for database developers and administrators focuses on language

features and how they are interpreted and processed by the SQL Server execution

engine.

Table of Contents

Inside Microsoft SQL Server 2005— T-SQL Programming

Foreword

Preface

Introduction

Chapter 1

-

Datatype-Related Problems, XML, and CLR

UDTs

Chapter 2

-

Temporary Tables and Table

Variables

Chapter 3

-

Cursors

Chapter 4

-

Dynamic SQL

Chapter 5

-

Views

Chapter 6

-

User-Defined

Functions

Chapter 7

-

Stored

Procedures

Chapter 8

-

Triggers

Chapter 9

-

Transactions

Chapter 10

-

Exception

Handling

Chapter 11

-

Service Broker

Appendix A

-

Companion to CLR

Routines

Index

List of Figures

List of Tables

List of Listings

List of Sidebars

|||No. You want T-SQL QUERYING (not programming).