Advice on dynamically generating RDL files

I would prefer to dynamically create my RDL files on the fly instead of
building them ahead of time. My question is this: the creation of these files
would occur on the server, but the reporting server may or may not be the
same box. Is the best way to upload the RDL file to use the web service
interface and import it, or are there other options here?
Thanks!
MichaelHi moflaherty,
You can create your RDL on the fly, the creation of the files can be
located at the client or server side, it does not matter as long you can
create the XML/RDL after that you can use the WS interface to upload them
into the server. In this example
http://www.rdlcomponents.com/ASPExamples/Default.aspx?sm=b1_a
You can see how the RDL creation process is isolated from the upload process.
Thanks
JErry
"moflaherty" wrote:
> I would prefer to dynamically create my RDL files on the fly instead of
> building them ahead of time. My question is this: the creation of these files
> would occur on the server, but the reporting server may or may not be the
> same box. Is the best way to upload the RDL file to use the web service
> interface and import it, or are there other options here?
> Thanks!
> Michael
>sql

Advantages of Stored Procedures?

Hi,
Generally I write all my SQL in Stored Procedures instead of using adhoc queries. But I dont feel good about stored procedures when I come across situations like this.

Lets say that I have a stored procedure something like this

CREATE PROCEDURE dbo.proc_MYSP
@.CaseID char(10)
AS
SELECT * FROM TABLE1WHERE CASEID = @.CASEID

Suppose in future if the field CASEID is changed to char(20) then I need to change the declaration of CaseID in all my stored procedures that take CaseID as input parameter. If I write adhoc queries then I need not worry about this. Is there any effective solution for a situation like this.

Thank you.>>If I write adhoc queries then I need not worry about this...

you will have that prob no matter if you use stored procs or adhoc queries. you'd still need to make the changes whereever req'd. its just less pain to make the changes in the stored procs than asp pages. business logic is best kept at the backend. its like a rule.

hth|||mndinkar, I seriously hope you meant this as a joke. See:

::you will have that prob no matter if you use stored procs or adhoc queries. you'd still need
::to make the changes whereever req'd. its just less pain to make the changes in the stored
::procs than asp pages. business logic is best kept at the backend. its like a rule.

There is a couple of things that need to be ccorrected here.

First, you seriously oversimplify. See, we do pretty complex apps. I use dynamic SQL. Still I haeve no sql at all in any ASP page. Basically: dude, get real. THere is a lot you can make between writing SP's and putting the SQL into asp pages. Stuff like working with classes. Or, if you want to be primitive, stuff like centralising all your SQL statements in one class.

Second, basically, a SP like the one shown above - nothing more than a select - givesyou nothing but adds. It is another layer that has to be maintained, and it is one that is badly integrated into the development environment (integration with VSS, for example, or the requirements for debugging). How can maintaining more than you have be less painfull? When you gain nothing and only loose?

Third, the statement that business logic per se is best kept at the backend is bordering on irresponsibility. The complete school of modern software architecture goes against putting business logic into the data store. Multi tiered applications are the modern concept of how to make software, and no, they are not about dumping all your business logic into the database. Quite the contrary.

Don't get met wrong, there is nothing wqrong with using SP's iin certain situations. Just when you advice to use them - no. They just cost you.|||Take a look at this, it's a very good cool headed approach to the issues.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/storedprocsnetdev2.asp|||And for a good hot-headed discussion on the issue, see Rob Howard's classic blog post and repliesDon't use stored procedures yet? Must be suffering from NIHS (Not Invented Here Syndrome) And of course Frans Bouma's rebuttal blog postStored procedures are bad, m'kay?.

I at least thought it was interesting reading.

Terri|||those were interesting links terri. got to know a few things. thanks.

Advanced Data Shaping - Multiple Relate clause

Hello,

I'm using a shape query, but instead of using a simple clause "RELATE
field1 to field2" (relates the parent to the child), i wan't to use 2
relates. somthing like "RELATE field1 to field2 AND field3 to field4".

I want to receive in the children RS only the records who apply both
conditions.

How do i do that ?

Thanks !(doar123@.gmail.com) writes:
> I'm using a shape query, but instead of using a simple clause "RELATE
> field1 to field2" (relates the parent to the child), i wan't to use 2
> relates. somthing like "RELATE field1 to field2 AND field3 to field4".
> I want to receive in the children RS only the records who apply both
> conditions.
> How do i do that ?

I suspect that a newsgroup on ADO is better fitted for this question.

Or try Google. Entering SHAPE APPEND RELATE led me to
http://support.microsoft.com/default.aspx?scid=189657 which a
appears to have the answer you are looking for.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||I havn't tryed. My idea: Create a field in the parent rs wich contains
both field1 and field2. For example:
Fieldx = cast(field1 as char(10)) + cast(field2 as char(10))
Do this in the child-rs, too and relate them with the Fieldx

Michael

www.zankl-it.de

Advance SQL

Dear Expert,

How can I reuse the column, instead of select the whole things again.
Example as below :

select
column1 as A,
column2 as B,
column3 * A as C
from dummy ;

in MS SQL I have to do like this,

select
column1 as A,
column2 as B,
column3 * column1 as C
from dummy ;

Thanks

DesmondOn 1 Jun 2004 03:56:08 -0700, Desmond wrote:

>Dear Expert,
>How can I reuse the column, instead of select the whole things again.
>Example as below :
>select
> column1 as A,
> column2 as B,
> column3 * A as C
>from dummy ;
>in MS SQL I have to do like this,
>select
> column1 as A,
> column2 as B,
> column3 * column1 as C
>from dummy ;
>
>Thanks
>Desmond

Hi Desmond,

You can use a derived table:

select A, B, column3 * A as C
from (select column1 as A,
column2 as B,
column3
from dummy) AS t

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)|||>> How can I reuse the column, instead of selecting the whole thing
again. <<

You can put it into a VIEW or derived table:

SELECT a, b, a*column3 AS c
FROM (SELECT column1, column2, column3
FROM Dummy) AS X(a, b, column3);

But that is not your problem. The real problem is that you do not
understand how SQL -- real SQL -- works.

Here is how a SELECT works in SQL ... at least in theory. Real
products will optimize things when they can.

a) Start in the FROM clause and build a working table from all of the
joins, unions, intersections, and whatever other table constructors
are there. The table expression> AS <correlation name> option allows
you give a name to this working table which you then have to use for
the rest of the containing query.

b) Go to the WHERE clause and remove rows that do not pass criteria;
that is, that do not test to TRUE (reject UNKNOWN and FALSE). The
WHERE clause is applied to the working set in the FROM clause.

c) Go to the optional GROUP BY clause, make groups and reduce each
group to a single row, replacing the original working table with the
new grouped table. The rows of a grouped table must be group
characteristics: (1) a grouping column (2) a statistic about the group
(i.e. aggregate functions) (3) a function or (4) an expression made up
those three items.

d) Go to the optional HAVING clause and apply it against the grouped
working table; if there was no GROUP BY clause, treat the entire table
as one group.

e) Go to the SELECT clause and construct the expressions in the list.
This means that the scalar subqueries, function calls and expressions
in the SELECT are done after all the other clauses are done. The "AS"
operator can also give names to expressions in the SELECT list. These
new names come into existence all at once, but after the WHERE clause,
GROUP BY clause and HAVING clause has been executed; you cannot use
them in the SELECT list or the WHERE clause for that reason.

If there is a SELECT DISTINCT, then redundant duplicate rows are
removed. For purposes of defining a duplicate row, NULLs are treated
as matching (just like in the GROUP BY).

f) Nested query expressions follow the usual scoping rules you would
expect from a block structured language like C, Pascal, Algol, etc.
Namely, the innermost queries can reference columns and tables in the
queries in which they are contained.

g) The ORDER BY clause is part of a cursor, not a query. The result
set is passed to the cursor, which can only see the names in the
SELECT clause list, and the sorting is done there. The ORDER BY
clause cannot have expression in it, or references to other columns
because the result set has been converted into a sequential file
structure and that is what is being sorted.

As you can see, things happen "all at once" in SQL, not from left to
right as they would in a sequential file/proceudral language model. In
those languages, these two statements produce different results:
**READ (a, b, c) FROM File_X;
**READ (c, a, b) FROM File_X;

while these two statements return the same data:

SELECT a, b, c FROM Table_X;
SELECT c, a, b FROM Table_X;

Think about what a confused mess this statement is in the SQL model.

SELECT f(c2) AS c1, f(c1) AS c2 FROM Foobar;

That is why such nonsense is illegal syntax.