|
Posted by Lucky on 06/26/06 09:15
I'm quite dissappointed with your Questions. what i wanted to do so far
is to use output of the stored procedure in the select statement of the
Declaring CURSOR. but you have diverted the conversation on the
different track.
-- first i clearly said in my first post that i'm using MS SQL Server
2000 and .NET 2.0
-- for your convinience i gave you expamle of declaring cursor that i
had copied form the ms sql help but instead of understanding the
problem you complained about the syntaxt though that example was for to
understand the problem but you missed the target.
-- PL SQL is of course in Oracle to write some custom business logic.
the same way you can do in SQL Server the name used in here is T-SQL.
it shouldn't be hard for you to understand.
-- As far as i know, nobody ever asked me what kind of business logic i
want to use. we always disscus problems here and asked for the
solution.
-- what kind of businees logic i'm using and why i'm using and what
should be the size of the logic. these all depends on the requirements
and the scererios. i didn't ask your opinion on that.
We have streached the conversation to far and i dont want to continue
it further more.
thanks for nothing. and by the way i found what i was looking for.
Lucky
Erland Sommarskog wrote:
> Lucky (tushar.n.patel@gmail.com) writes:
> > yeah there is no table. its just a database list that i need.
>
> So how does the actual cursor declaration look like? The code you
> posted was incorrect, as it referred to a non-existing column. It's
> very difficult to assist when I don't really know what you are trying
> to do.
>
> > and the business logic is very very big to paste here. i need some
> > different tables in different DB and the idea of using the foreachloop
> > is interesting but i dont know wether it will work with more than 250
> > lines of PL SQL code.
>
> PL/SQL? What are you using? MS SQL Server or Oracle?
>
> To me it sounds very funny of wanting to run 250 lines of business logic
> in multiple databases. I can envision situations where this may be
> necessary, but I can also see this as a result of a poor design.
>
> If you explained what your are actually trying to achieve in business
> terms, it may be easier to suggest a good solution.
>
> For a general discussion on multiple databases, this section in my
> article on dynamic SQL may give some ideas:
> http://www.sommarskog.se/dynamic_sql.html#Dyn_DB.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
[Back to original message]
|