Localization in SQL Server 2000

Hi.

I have distributed databases in different language versions, I am creating a stored procedure, and this problably in future is going to be migrated to other SQL Server database. the query that I have inside the stored procedure is this:

Insert Into Prueba Values(14,'31/07/1999') ---> format date of this query is in Hispanic version (this works fine)

But, If this query is migrated to other SQL Server and it's version would be in English, that query wouldn't work, the principal reason is the format date.

Solution that I have on mind is creating a stored procedure that receives three parameters the month,day and year. I want to identify the localization of that SQL Server database and use "IF" conditions and inside of these concatenate month,day and year obviously depending of the date format identified through "IF" conditions.

If somebody has an idea to solve this or somebody knows how to identify the locatization in an SQL Server database I would be thankful.

Thank you again and best regards.

Christian

Hello my friend,

You do not need to do this. Instead, change the way string dates are interpreted in your stored procedure by using the SET DATEFORMAT command in the procedure before parsing the date. Run the following to see what I mean: -

DECLARE @.datevar varchar(50)
SET @.datevar = '2007/08/04'

SET DATEFORMAT ymd
SELECT MONTH(@.datevar)

SET DATEFORMAT ydm
SELECT MONTH(@.datevar)

Kind regards

Scotty

|||

Thank you so much...

I know it's going to work fine.

Thank you so much again !!

local and distributed transaction

Hi all,
Depending on a parameter in a sp, I have to do work either locally or
remotely.
The work to be done is the same in both case.
I wrote:
if @.param = 1
begin transaction
else
begin DISTRIBUTED transaction
/* do the work */
commit transaction
Does anyone knows if Microsoft have stated any recommandation on not writing
code like that (that is not having both type of transaction in the same
place) ?
ThanksHi
though logically what you have given is right, I feel you can use a
distributed transaction for both cases and live with out the if condition.
distributed transactions can also work locally.|||Hi,
Thanks for the answer.
Do you know if there might be any performance penlaty using distributed
transaction locally ?
"Omnibuzz" wrote:

> Hi
> though logically what you have given is right, I feel you can use a
> distributed transaction for both cases and live with out the if condition.
> distributed transactions can also work locally.|||Technically there shouldn't be any difference since if there are no other
resource managers that are participating in the distirbuted transaction
except the local server. Infact SQL Server uses a distirbuted transaction
spanning across databases within the same server. I feel it should be fine t
o
use it.
But if you are uncomfortable about this, u can use two SPs one having the
local transaction and one for the distirbuted transaction. It will look
better than the approach you have suggested. Hope this helps.|||A still better solution. You will have to check it though.
Add this line to the beginning of the proc
SET REMOTE_PROC_TRANSACTIONS ON
and use "begin transaction".
On a remote procedure call, it will promote the local transaction to
distirbuted trasanction, else will keep it as a local transaction.
Hope this helps.