Hi,
I am trying to work on a stored procedure that will work with multiple
database. I have a prototype of multiple databases. Those are named as the
following: ts2_aldkm_app, ts2_aldkp_app, ts2_aldkt_app. The middle part of
the database name corresponds to the site name e.g aldkm corresponds to site
aldkm etc. Each database has one table tblCustomer which is scripted as
follows:
if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblcustomer]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[tblcustomer]
GO
CREATE TABLE [dbo].[tblcustomer] (
[RecKey] [int] NOT NULL ,
[CustID] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[sales_ytd] [money] NULL ,
[sales_lstyr] [money] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
Now I need to create a stored procedure that should work with any of the
three ( or more ) database if proper parameters are passed. I need to pass
the database name, custid, sales_ytd, sales_lstyr and a sql paramter to
process the database name.
When I am creating the stored procedure I am getting the following error:
Server: Msg 306, Level 16, State 1, Procedure process_customer, Line 13
The text, ntext, and image data types cannot be compared or sorted, except
when using IS NULL or LIKE operator.
I am not sure why I am not getting this error. Any help to resolve this is
highly appreciated. Thanks.
STORED PROCEDURE CODE:
create procedure process_customer
--DECLARE
@dbname varchar(255),
@custid int,
@sales_ytd money,
@sales_lstyr money,
@site varchar(10),
@SQL varchar(50)
as
set @dbname = 'ts2_' + @site + '_app'
set @SQL = 'use ' + @dbname
select custid, sales_ytd, sales_lstyr
from tblcustomer
where
custid = @custid
and sales_ytd = @sales_ytd
and sales_lstyr = @sales_lstyr
Cowboy (Gregory A. Beamer) - 21 Jul 2008 17:26 GMT
Your CustID is the text datatype. Any reason for this? It is an ID, after
all. How large can it get? I note that you are sending an int in for custid
in the sproc.

Signature
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss
or just read it:
http://gregorybeamer.spaces.live.com/
********************************************
| Think outside the box! |
********************************************
> Hi,
> I am trying to work on a stored procedure that will work with multiple
[quoted text clipped - 53 lines]
> and sales_ytd = @sales_ytd
> and sales_lstyr = @sales_lstyr
Eric Russell - 21 Jul 2008 19:05 GMT
In your sample stored procedure below, I see where you are doing this as if
using dynamic SQL:
...
set @SQL = 'use ' + @dbname
...
However, I don't see where you are calling the exec() function. I don't know
about the error, but if part of your question is about how to write a stored
procedure that can query across tables in multiple database or execute within
the context of different databases, then perhaps these two excellent articles
listed below will help.
If your production system will have a seperate database for each client, and
you need to perform reporting queries across multiple clients, then I would
reccomend the partitioned view approach. You basically create a view that
unionizes the same table across multiple databases (or servers). For example:
create view vCustomer as
select a, b, c from ts2_aldkm_app.dbo.tblCustomer
union
select a, b, c from ts2_aldkp_app.dbo.tblCustomer
union
select a, b, c from ts2_aldkt_app.dbo.tblCustomer
go
SQL Server 2000 Partitioned Views
http://www.fotia.co.uk/fotia/FA.02.Sql2KPartitionedViews.01.aspx#IntroducingPart
itionedViews
As for dynamic SQL, I've found that anything other than the simplist queries
of a few lines becomes unbearable and prone to errors, and I would rather
just deploy multiple copies of the stored procedures in each database.
The curse and blessings of dynamic SQL
http://www.sommarskog.se/dynamic_sql.html#EXEC4
> Hi,
> I am trying to work on a stored procedure that will work with multiple
[quoted text clipped - 51 lines]
> and sales_ytd = @sales_ytd
> and sales_lstyr = @sales_lstyr
Jack - 21 Jul 2008 21:51 GMT
Thanks a lot for all the help to Roy Andrew and Eric. I appreciate it.
> In your sample stored procedure below, I see where you are doing this as if
> using dynamic SQL:
[quoted text clipped - 85 lines]
> > and sales_ytd = @sales_ytd
> > and sales_lstyr = @sales_lstyr
Alex Kuznetsov - 21 Jul 2008 19:16 GMT
> Hi,
> I am trying to work on a stored procedure that will work with multiple
[quoted text clipped - 51 lines]
> and sales_ytd = @sales_ytd
> and sales_lstyr = @sales_lstyr
DO you really need to have 50 separate databases? Are you considering
consolidating all 50 into one?
Jack - 21 Jul 2008 19:39 GMT
There will be 50 different databases corresponding to 50 different sites. For
now the requirement is to come up with a procedure that will process table
information corresponding to database that is to be used bases on the site
parameter. Thanks.
> > Hi,
> > I am trying to work on a stored procedure that will work with multiple
[quoted text clipped - 54 lines]
> DO you really need to have 50 separate databases? Are you considering
> consolidating all 50 into one?
Alex Kuznetsov - 21 Jul 2008 19:45 GMT
> There will be 50 different databases corresponding to 50 different sites. For
> now the requirement is to come up with a procedure that will process table
> information corresponding to database that is to be used bases on the site
> parameter. Thanks.
Are you sure that the decision to have 50 different databases
corresponding to 50 different sites is a good one? Are you in a
position to reconsider this decision?
Alex Kuznetsov - 21 Jul 2008 19:48 GMT
> > There will be 50 different databases corresponding to 50 different sites. For
> > now the requirement is to come up with a procedure that will process table
[quoted text clipped - 4 lines]
> corresponding to 50 different sites is a good one? Are you in a
> position to reconsider this decision?
Oops - hit send too soon.
Based only on your post and some previous experience, to me it looks
like the ugly downstream ramifications of this decision are just
beginning to show up. Of course you have a much better perspective.
Jack - 21 Jul 2008 21:09 GMT
Alex for now that's the decision which may change in the near future for
consolidation. I have to deal with the present issue now. Thanks. The
designing has been done by outside consultants. They were the ones who made
the decisions.
> > > There will be 50 different databases corresponding to 50 different sites. For
> > > now the requirement is to come up with a procedure that will process table
[quoted text clipped - 10 lines]
> like the ugly downstream ramifications of this decision are just
> beginning to show up. Of course you have a much better perspective.
Andrew J. Kelly - 21 Jul 2008 21:51 GMT
They told you you should do it that way but didn't tell you how or why. You
can't come up with a complete solution by looking only at the logical model,
you have to take into consideration how you will implement and maintain that
as well. I would think twice about using them again:).

Signature
Andrew J. Kelly SQL MVP
Solid Quality Mentors
> Alex for now that's the decision which may change in the near future for
> consolidation. I have to deal with the present issue now. Thanks. The
[quoted text clipped - 19 lines]
>> like the ugly downstream ramifications of this decision are just
>> beginning to show up. Of course you have a much better perspective.
Jack - 21 Jul 2008 22:03 GMT
Andrew,
I totally concur with your opinion. Here when management are the 'deciders'
. IT staff has not too much of a say, at least in my company but get rapid
solutions out to the issues and problems. Regards.
> They told you you should do it that way but didn't tell you how or why. You
> can't come up with a complete solution by looking only at the logical model,
[quoted text clipped - 24 lines]
> >> like the ugly downstream ramifications of this decision are just
> >> beginning to show up. Of course you have a much better perspective.
Eric Russell - 22 Jul 2008 15:07 GMT
There may be security or compliance reasons why management wants each
client's data segmented into seperate databases within the online transaction
processing server. You may consider implementing a [datamart] that
consolidates transactional or summary data across all OLTP databases into one
server/database for the purpose of reporting or data analysis.
> Andrew,
> I totally concur with your opinion. Here when management are the 'deciders'
[quoted text clipped - 29 lines]
> > >> like the ugly downstream ramifications of this decision are just
> > >> beginning to show up. Of course you have a much better perspective.