How can I conserve the initial zero when convert numeric to string using STR()

Sorry to raise a stupid question but I tried many methods which did
work.
how can I conserve the initial zero when I try to convert STR(06) into
string in SQL statment?
It always gives me 6 instead of 06.

Thanks a lot.You can't "preserve" the zero. Integer 06 = Integer 6 = Integer
00000000006.

If you want to convert an integer to a varchar you can prepend a 0 character
to the result:

SELECT '0' + CAST(06 AS VARCHAR)

Returns '06'. The downside to this method is that if you do something like

SELECT '0' + CAST(10 AS VARCHAR)

You'll end up with '010' which may or may not be what you want. You can
build on this example with the SUBSTRING function to get exactly what you
really want out of it.

<angellian@.gmail.com> wrote in message
news:1148779910.070643.296910@.g10g2000cwb.googlegr oups.com...
> Sorry to raise a stupid question but I tried many methods which did
> work.
> how can I conserve the initial zero when I try to convert STR(06) into
> string in SQL statment?
> It always gives me 6 instead of 06.
> Thanks a lot.|||You are confusing the PHYSICAL display with the internal LOGICAL model.

This is SQL and not COBOL. There is no initial zero in a number; there
is an internal binary, BCD or whatever the hard uses representation.

Your next problem is that you do not understand that dispaly is NEVER
done in the database, but in the front end application. That is the
most basic concept of *any* tiered architecture, not just SQL.|||--CELKO-- (jcelko212@.earthlink.net) writes:
> Your next problem is that you do not understand that dispaly is NEVER
> done in the database, but in the front end application. That is the
> most basic concept of *any* tiered architecture, not just SQL.

Working so long as you have done in the database trade should have learnt
you to never say never.

There is at least one obvious case where formatting of output must be
done in SQL: to wit when the display is done in a standard query tool
like Query Analyzer. Which typically is the case for admin stuff.

--
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|||> This is SQL and not COBOL. There is no initial zero in a number; there
> is an internal binary, BCD or whatever the hard uses representation.

This is SQL SERVER not SQL and not COBOL, SQL SERVER has many facilities to
aid the developer in creating a highly scalable, robust and maintainable
architecture.

Standard SQL is very weak in terms of features that we need out in the real
world.

> Your next problem is that you do not understand that dispaly is NEVER
> done in the database, but in the front end application. That is the
> most basic concept of *any* tiered architecture, not just SQL.

"Display" can never be done in the database because the database is a
service and has such has no UI, we use tools to get at the data.

The big problem here is your continued misconception that ALL formatting
should be done in the front end application, have you actually sat down and
thought about what that means? The fundemental principle of tiered
architecture design and development is that formatting is done where it is
most sensible and efficient, in terms of development and support cost and in
terms of performance.

My blog entry on this covers in more detail:
http://sqlblogcasts.com/blogs/tonyr.../05/11/429.aspx

I see you use CTE, why don't you pull the results down into the application,
CTE's are a form of formatting for display purposes, as is COALESCE on the
SELECT clause, as is ORDER BY etc... Just where do you draw the line?

Anyway, you are still stuck in the mainframe model of all resources are in
the same box and that you use the VTAM protocol out to remote terminals.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials

"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1148830663.994422.182500@.y43g2000cwc.googlegr oups.com...
> You are confusing the PHYSICAL display with the internal LOGICAL model.
>
> This is SQL and not COBOL. There is no initial zero in a number; there
> is an internal binary, BCD or whatever the hard uses representation.
> Your next problem is that you do not understand that dispaly is NEVER
> done in the database, but in the front end application. That is the
> most basic concept of *any* tiered architecture, not just SQL.|||Something like this may help...Assuming your column name is COLUMN1 and
COLUMN1 has a numeric type.

select case
when COLUMN1 < 10 then '0' + cast(COLUMN1 as varchar(10))
end
when COLUMN1 > = 10 then cast(COLUMN1 as varchar(10)) end
......(rest of your statement...)

Hope this helps...|||Hi Angellian,

For 2 character string you can just use CASE...

declare @.number tinyint
set @.number = 2

select case when @.number between 0 and 9 then '0' else '' end + cast(
@.number as varchar(2) )

Otherwise, if your resultant string needs to be bigger than 2 characters do
this...

declare @.number int
declare @.string varchar(10)
declare @.size_of_fixed_string tinyint
set @.size_of_fixed_string = 10
set @.number = 40

print replicate( '0', @.size_of_fixed_string )

set @.string = left( replicate( '0', @.size_of_fixed_string ),
@.size_of_fixed_string - len( @.number ) ) + cast( @.number as varchar(10) )

print @.string

http://sqlblogcasts.com/blogs/tonyr.../05/29/765.aspx

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials

<angellian@.gmail.com> wrote in message
news:1148779910.070643.296910@.g10g2000cwb.googlegr oups.com...
> Sorry to raise a stupid question but I tried many methods which did
> work.
> how can I conserve the initial zero when I try to convert STR(06) into
> string in SQL statment?
> It always gives me 6 instead of 06.
> Thanks a lot.|||>> There is at least one obvious case where formatting of output must be done in SQL: to wit when the display is done in a standard query tool like Query Analyzer. <<

No, that formatting is done in the Query Analyzer, which is a program
and not part of SQL. Trust me, we never voted on a "standard query
tool" in ANSI X3H2.|||>> I see you use CTE, why don't you pull the results down into the application, CTE's are a form of formatting for display purposes, as is COALESCE on the SELECT clause, as is ORDER BY etc... Just where do you draw the line? <<

UNH? CTEs are virtual tables and have nothing to do with display. Do
ypou also think that VIEWs and derived tables are formatting for user
display? COALESCE is a function that works with NULLs and CAST() to
get another internal data type result.

Things like CONVERT() on dates or PRINT in T-SQL is formatting.|||Just cause I've seen a couple of examples using CASE; I use trick
similar to your second example:

SELECT RIGHT('0' +CONVERT(varchar(2), @.number), 2)

Granted, it only works on a two-digit number, but it saves typing. The
REPLICATE idea is pretty smooth, though.

Stu

Tony Rogerson wrote:
> Hi Angellian,
> For 2 character string you can just use CASE...
> declare @.number tinyint
> set @.number = 2
> select case when @.number between 0 and 9 then '0' else '' end + cast(
> @.number as varchar(2) )
> Otherwise, if your resultant string needs to be bigger than 2 characters do
> this...
> declare @.number int
> declare @.string varchar(10)
> declare @.size_of_fixed_string tinyint
> set @.size_of_fixed_string = 10
> set @.number = 40
> print replicate( '0', @.size_of_fixed_string )
> set @.string = left( replicate( '0', @.size_of_fixed_string ),
> @.size_of_fixed_string - len( @.number ) ) + cast( @.number as varchar(10) )
> print @.string
> http://sqlblogcasts.com/blogs/tonyr.../05/29/765.aspx
> --
> Tony Rogerson
> SQL Server MVP
> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
> Server Consultant
> http://sqlserverfaq.com - free video tutorials
>
> <angellian@.gmail.com> wrote in message
> news:1148779910.070643.296910@.g10g2000cwb.googlegr oups.com...
> > Sorry to raise a stupid question but I tried many methods which did
> > work.
> > how can I conserve the initial zero when I try to convert STR(06) into
> > string in SQL statment?
> > It always gives me 6 instead of 06.
> > Thanks a lot.|||--CELKO-- wrote:
> >> I see you use CTE, why don't you pull the results down into the application, CTE's are a form of formatting for display purposes, as is COALESCE on the SELECT clause, as is ORDER BY etc... Just where do you draw the line? <<
> UNH? CTEs are virtual tables and have nothing to do with display. Do
> ypou also think that VIEWs and derived tables are formatting for user
> display? COALESCE is a function that works with NULLs and CAST() to
> get another internal data type result.
> Things like CONVERT() on dates or PRINT in T-SQL is formatting.

Hi Joe,

I didn't understand Tony's point about CTEs, but I think his point
about COALESCE stands. Surely, COALESCE is shorthand for having
formatting code at the front end like:

If Column1 is not null then
show Column1
Else if column2 is not null then
show Column2
Else if column3 is not null then
:
:
:
Else
show ColumnN
End If

Damien|||> UNH? CTEs are virtual tables and have nothing to do with display. Do
> ypou also think that VIEWs and derived tables are formatting for user
> display? COALESCE is a function that works with NULLs and CAST() to
> get another internal data type result.
> Things like CONVERT() on dates or PRINT in T-SQL is formatting.

Ok - I conceede CTEs, I was thinking about them within the scope of paging
on which you have in the past stated you would have the front end perform,
that literally means pushing a million rows over the network to the front
end.

> Things like CONVERT() on dates or PRINT in T-SQL is formatting.

The operator was trying to create a string with leading zeros which you
stated should be done in the front end.

Why on earth would you want to go to all the effort of using a 3GL / 4GL to
format the data when you can just simply do it in TSQL within the SQL Server
itself - nice and simple, nice and easy to support and maintain.

Your method relies on additional skills, the developer would need to
understand a programming language as well as SQL, that then translates into
a support and maintanence burden which costs money.

You can very easily do the formatting in the TSQL and use Integration
Services or DTS to export the data out to whatever you want - XML, XLS
etc...

Your recommendations around formatting date back to the 70's where rdbms
didn't have many facilities available for the developer other than SUM,
COUNT, MIN, MAX and AVG.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials

"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1149114884.873451.172270@.g10g2000cwb.googlegr oups.com...
>>> I see you use CTE, why don't you pull the results down into the
>>> application, CTE's are a form of formatting for display purposes, as is
>>> COALESCE on the SELECT clause, as is ORDER BY etc... Just where do you
>>> draw the line? <<
> UNH? CTEs are virtual tables and have nothing to do with display. Do
> ypou also think that VIEWs and derived tables are formatting for user
> display? COALESCE is a function that works with NULLs and CAST() to
> get another internal data type result.
> Things like CONVERT() on dates or PRINT in T-SQL is formatting.|||>> Why on earth would you want to go to all the effort of using a 3GL / 4GL
>> to format the data when you can just simply do it in TSQL within the SQL
>> Server itself - nice and simple, nice and easy to support and maintain.

The general answer is that one would prefer to have the centralized database
as generic as possible so that it can support a variety of applications.

Having an application specific formatting at the central data source tend to
generate something called "application bias". Considering the OP's question,
given certain 5 applications requesting same data formatted in 5 different
ways, should he formulate a single generic query and do the formatting in
the application or should he create 5 different queries to support each
application? How about when the number of applications increases to 50? Or
say 500?

While it may appear to be efficient and easy to manage in the short term, it
can often be highly detrimental to the long term stability and management of
data centric systems.

This is nothing new but such bias is known to software engineers for decades
now. For details on why this separation of concern is important for data
oriented systems, ~Principles of Program Design~ by Michael Jackson is a
good book.

--
Anith|||--CELKO-- (jcelko212@.earthlink.net) writes:
>>> There is at least one obvious case where formatting of output must be
done in SQL: to wit when the display is done in a standard query tool like
Query Analyzer. <<
> No, that formatting is done in the Query Analyzer,

QA only has a standard formatting, with no options to specify a how a
certainly column should look like.

Thus, if you want a certain format when you look at the data in QA, SQL
is the only place to do formatting.

> which is a program and not part of SQL. Trust me, we never voted on a
> "standard query tool" in ANSI X3H2.

I never said so. I only meant to say that it is a plain query tool,
and about every RDBMS comes with one.

--
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|||Anith Sen (anith@.bizdatasolutions.com) writes:
> The general answer is that one would prefer to have the centralized
> database as generic as possible so that it can support a variety of
> applications.

I think the Perl has the right answer to this: There is more than one
way do it!

That is, if you can do things either in the server or the in the client/
middile layer, you can pick what fits best for the situation.

--
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 think of it the other way round, surely the 5 applications would call 1
single query and not different queries for different applications.

SQL Server is more a service orientated architecture, well - becoming that
anyway.

So, doing things centrally in the SQL Server is better because you only need
do it once and not in 5 places in 5 different langauges requiring 6
different skill sets.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials

"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:e5n83p$v6r$1@.nntp.aioe.org...
>>> Why on earth would you want to go to all the effort of using a 3GL / 4GL
>>> to format the data when you can just simply do it in TSQL within the SQL
>>> Server itself - nice and simple, nice and easy to support and maintain.
> The general answer is that one would prefer to have the centralized
> database as generic as possible so that it can support a variety of
> applications.
> Having an application specific formatting at the central data source tend
> to generate something called "application bias". Considering the OP's
> question, given certain 5 applications requesting same data formatted in 5
> different ways, should he formulate a single generic query and do the
> formatting in the application or should he create 5 different queries to
> support each application? How about when the number of applications
> increases to 50? Or say 500?
> While it may appear to be efficient and easy to manage in the short term,
> it can often be highly detrimental to the long term stability and
> management of data centric systems.
> This is nothing new but such bias is known to software engineers for
> decades now. For details on why this separation of concern is important
> for data oriented systems, ~Principles of Program Design~ by Michael
> Jackson is a good book.
> --
> Anith

How can I combine two report parameters into a string?

Sorry, I am new to the SQL reporting. I am not sure whether I can combine
two report parameters in a string and then use it in my querystring or not.
For example, I have a report paramter called "Month" and the other one
called "Year". Obviously I want to make them as a start date for my report
and them pass this into my querystring. Can I achieve this without writing a
stored procedure for this purpose?
ThanksUse the command type of text.
exec sp_my_stored_procedure @.Month + @.Year, @.Param3, @.Param4
or
select * from table where date = @.Month + @.Year
--
Harolds
"Laipond" wrote:
> Sorry, I am new to the SQL reporting. I am not sure whether I can combine
> two report parameters in a string and then use it in my querystring or not.
> For example, I have a report paramter called "Month" and the other one
> called "Year". Obviously I want to make them as a start date for my report
> and them pass this into my querystring. Can I achieve this without writing a
> stored procedure for this purpose?
> Thanks|||Harolds,
Thanks for the reply. I have tried the way you mentioned below. Following
is what I did and the result I got:
Case 1. In "Define Query Parameter" dialog box, I type 3/1/2005 for @.month,
and leave @.year blank. The reporting service can successfully pull the data.
Case 2. In "Define Query Parameter" dialog box. I type 3/1/ for @.month and
2005 for @.year. An error happen: "Application uses a value of the wrong type
for the current operation."
Is there any other function I can apply for this query string to make it work?
Thanks
Laipond
"Harolds" wrote:
> Use the command type of text.
> exec sp_my_stored_procedure @.Month + @.Year, @.Param3, @.Param4
> or
> select * from table where date = @.Month + @.Year
> --
> Harolds
>
> "Laipond" wrote:
> > Sorry, I am new to the SQL reporting. I am not sure whether I can combine
> > two report parameters in a string and then use it in my querystring or not.
> >
> > For example, I have a report paramter called "Month" and the other one
> > called "Year". Obviously I want to make them as a start date for my report
> > and them pass this into my querystring. Can I achieve this without writing a
> > stored procedure for this purpose?
> >
> > Thanks|||You are getting that error because you have @.Month and/or @.Year set to a
datetime data type instead of string.
--
Harolds
"Laipond" wrote:
> Harolds,
> Thanks for the reply. I have tried the way you mentioned below. Following
> is what I did and the result I got:
> Case 1. In "Define Query Parameter" dialog box, I type 3/1/2005 for @.month,
> and leave @.year blank. The reporting service can successfully pull the data.
> Case 2. In "Define Query Parameter" dialog box. I type 3/1/ for @.month and
> 2005 for @.year. An error happen: "Application uses a value of the wrong type
> for the current operation."
> Is there any other function I can apply for this query string to make it work?
> Thanks
> Laipond
> "Harolds" wrote:
> > Use the command type of text.
> > exec sp_my_stored_procedure @.Month + @.Year, @.Param3, @.Param4
> > or
> > select * from table where date = @.Month + @.Year
> > --
> > Harolds
> >
> >
> > "Laipond" wrote:
> >
> > > Sorry, I am new to the SQL reporting. I am not sure whether I can combine
> > > two report parameters in a string and then use it in my querystring or not.
> > >
> > > For example, I have a report paramter called "Month" and the other one
> > > called "Year". Obviously I want to make them as a start date for my report
> > > and them pass this into my querystring. Can I achieve this without writing a
> > > stored procedure for this purpose?
> > >
> > > Thanks

How can I choose a query based on Parameter values

I have 3 parameter fields, last-name, middle-name, first-name
and the view/table of database has just one string combined of all
three(and it is NOT possible to split).
I need to provide search facility with any combination of these three
fields.
I am very new to this environs and would like to know how I can
achieve this.
Do I have to create an SP which checks if each of the fields is NULL
and do accordingly ?
any help will be appreciated
Thanks
BofoIf I understand what you want correctly you could do this:
select * from yourtable where name like '%' + @.FirstName + '%' + @.MiddleName
+ '%' + @.LastName + '%'
The above query doesn't care if a parameter is null, or has a space or a
partial first name, partial lastname etc (I don't know if they are putting
in the names freeform or picking from a listbox). Anyway, that should at
least give you an idea.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<bofobofo@.yahoo.com> wrote in message
news:55950c3f.0501271730.6d87c737@.posting.google.com...
>I have 3 parameter fields, last-name, middle-name, first-name
> and the view/table of database has just one string combined of all
> three(and it is NOT possible to split).
> I need to provide search facility with any combination of these three
> fields.
> I am very new to this environs and would like to know how I can
> achieve this.
> Do I have to create an SP which checks if each of the fields is NULL
> and do accordingly ?
> any help will be appreciated
> Thanks
> Bofo|||Hello Bruce,
Thanks for the advice. I have been trying queries in those lines but I
dont get the results.
I get the result only in the case where the Lastname, Middlename and
Firstname match.
for example
I have tried the following:
Name LIKE '%' + @.last + '%' + @.middle + '%' + @.first + '%' --> only
matches if all strings are provided.
Name LIKE '%' + @.last + '%' + @.first + '%' --> matches all with the
last and first
etc..
I can use an OR to consider all possibilities but when i have to
consider the cases when the user gives a single param i will always get
a bunch of results even when the user gives the fullname
For this reason i would like to know if I can put some PL/SQL logic for
diff cases but seems like that is not the way to go as my query is not
being accepted.
Is there any other way I can do this ? a Stored P ? any ideas how to
do it ?
Thanks very much
bofo|||I go it working. Using a stored procedure.
thanks

How can i add string type column as a measure

How can i add Fact table string type column as a measure.

What are you looking to do with the string?

Measures are usually numbers that can be summed (or some other additive/semi-additive function). If you have string datatypes in your fact table, and you're not just looking for a count, are those string values unique per row? If so, what you'll want to build is a degenerate dimension. If not, you'll want to pull that out into a separate dimension table and foreign key to it with an int surrogate key.

Search for the phrase "degenerate dimension" in the following paper:

http://msdn2.microsoft.com/en-us/library/ms345125(SQL.90).aspx

(Don't use ROLAP like he suggests unless MOLAP just doesn't work for you.)

How can control Transactions for creating Stored Procedure ?

I create StringBuilder type for

concating string to create a lot of stored procedure at once

However When I use this command

BEGIN TRANSACTION
BEGIN TRY
--////////////////////// SQL COMMAND /////////////////////////

------- This any command

--///////////////////////////////////////////////////////////
--COMMIT TRAN
END TRY

BEGIN CATCH
IF @.@.TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH

IF @.@.TRANCOUNT > 0
COMMIT TRANSACTION;

on any command

If I use

Create a lot of Tables

such as

BEGIN TRANSACTION
BEGIN TRY
--////////////////////// SQL COMMAND /////////////////////////

CREATE TABLE [dbo].[Table1](
Column1 Int ,
Column2 varchar(50) NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[Table2](
Column1 Int ,
Column2 varchar(50) NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[Table3](
Column1 Int ,
Column2 varchar(50) NULL
) ON [PRIMARY]

--///////////////////////////////////////////////////////////
--COMMIT TRAN
END TRY

BEGIN CATCH
IF @.@.TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH

IF @.@.TRANCOUNT > 0
COMMIT TRANSACTION;

It correctly works.

But if I need create a lot of Stored procedure

as the following code :

BEGIN TRANSACTION
BEGIN TRY
--////////////////////// SQL COMMAND /////////////////////////

CREATE PROCEDURE [dbo].[DeleteItem1]
@.ProcId Int,
@.RowVersion Int
AS
BEGIN
DELETE FROM [dbo].[ItemProcurement]
WHERE
[ProcId] = @.ProcId AND
[RowVersion] = @.RowVersion
END

CREATE PROCEDURE [dbo].[DeleteItem2]
@.ProcId Int
AS
BEGIN
DELETE FROM [dbo].[ItemProcurement]
WHERE
[ProcId] = @.ProcId
END

CREATE PROCEDURE [dbo].[DeleteItem3]
@.ProcId Int
AS
BEGIN
DELETE FROM [dbo].[ItemProcurement]
WHERE
[ProcId] = @.ProcId
END

--///////////////////////////////////////////////////////////
--COMMIT TRAN
END TRY

BEGIN CATCH
IF @.@.TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH

IF @.@.TRANCOUNT > 0
COMMIT TRANSACTION;

It occurs Error ???

Please help me

How should I solve them ?

the stored procedure create

CREATE PROCEDURE ..

have to be first in T-SQL command batch. You can do what you need by inserting each single procedure code into varchar(max) variable and run this code using EXEC command like

DECLARE @.lcCommand as varchar(max)

SET @.lcCommand ='CREATE PROCEDURE PROC1 .....'

EXEC (@.lcCommand)

SET @.lcCommand ='CREATE PROCEDURE PROC2 .....'

EXEC (@.lcCommand)

remember if you procedure definition is longer than 8000 chars split it into chunks not longer than 8000 chars to prevent errors( for some reason string passed to varchar(max) in single assign is cut at 8000 position if longer than 8000 chars)

How can connect SSAS w/o domain trusted connection?

I got error: An existing connection was forcibly closed by the remote host!!

string connstr = "Provider=MSOLAP.3;Data Source=amsserver;Password=;User ID=administrator;Initial Catalog=MIP2ASProject";

Client in XP, with AS9.0 provider installed, server is sqlserver 2005 in win2003 xp1.

Both machines are not under domain controller...

Moving to SQL Server Analysis Services forum.|||

Analysis Services does not support non-Windows authentication when connecting through TCP/IP.

You should be able to setup HTTP connectivity to SSAS.
See following:
http://www.microsoft.com/technet/prodtechnol/sql/2005/httpasws.mspx

And then use different type of authentication avaliable in IIS to connect to Analysis Server.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

How can a variable used in SQL select command

select * from TABLE where user='jacky' ,it can working,but if like this:
dim name as string="jacky"
select * from TABLE where user=name
it won't doing,Can a variable used in SQL select command,if can,how to make it working.You can, but you are missing some basic insights here ...

You can do this like this:

string sql = "Select * from TABLE where user = '" + name + "'"

OR use a stringbuilder of so ...

If you are using SQL Server or any decent DBMS, try using stored procedures instead|||Thank you very much!

How 2 create an effective search on NTEXT ?

Dear SQL,

since I create some multi-language table - I want to allow finding unicode text
so I made the field:Key_Words" (ntext)

It will have a string that can include some words in different languages, so that I can find by using:
SELECT Key_Words FROM MyTable WHERE Key_Words LIKE '%" & MyVar & "%' "...

The problem is that I can not apply clustered index onntext field (or *any* index...)

Any ideas how to deal with it ?SQL Server "large" edition and full text search.

Only way.|||Thanks,

I was trying to avoid reading about this stuff...

but I guess there is no escape 4 me :-(