Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data='DotaznXk je vyplněn!' where langid=5 and
resource_id=7
When querying the updated value I get
resource_ID langID data
7 5 DotaznXk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,
> Then I update the following row into the table:
> update usr_data set data='DotaznXk je vyplněn!' where langid=5 and
> resource_id=7
For a Unicode constant, prefix the literal with N:
UPDATE dbo.usr_data
SET data = N'DotaznXk je vyplněn!'
WHERE
langid = 5 AND
resource_id = 7
Note that Unicode allows all Unicode characters to be stored. The Unicode
collation affects only sorting and comparison.
Hope this helps.
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181645527.452234.163220@.x35g2000prf.googlegr oups.com...
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data='DotaznXk je vyplněn!' where langid=5 and
resource_id=7
When querying the updated value I get
resource_ID langID data
7 5 DotaznXk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,
|||Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02Xpm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data = N'DotaznXk je vyplněn!'
> WHERE
> X X langid = 5 AND
> X X resource_id = 7
> Note that Unicode allows all Unicode characters to be stored. XThe Unicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegr oups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data X X X X X X nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data='DotaznXk je vyplněn!' where langid=5 and
> resource_id=7
> When querying the updated value I get
> resource_ID langID X X Xdata
> X X X X X 7 X X X X X 5DotaznXk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,
|||> Only thing I wonder now, is how I could forget :-)
I'm glad I was able to help. I think you'll remember the 'N' the next time
;-)
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181646750.111306.272120@.z28g2000prd.googlegr oups.com...
Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02 pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data = N'DotaznXk je vyplněn!'
> WHERE
> langid = 5 AND
> resource_id = 7
> Note that Unicode allows all Unicode characters to be stored. The Unicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegr oups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data='DotaznXk je vyplněn!' where langid=5 and
> resource_id=7
> When querying the updated value I get
> resource_ID langID data
> 7 5 DotaznXk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,
Showing posts with label application. Show all posts
Showing posts with label application. Show all posts
Sunday, March 25, 2012
Collation issue?
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid=3D= 5 and
resource_id=3D7
When querying the updated value I get
resource_ID langID data
7 5 Dotazn=C3=ADk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,> Then I update the following row into the table:
> update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
> resource_id=7
For a Unicode constant, prefix the literal with N:
UPDATE dbo.usr_data
SET data = N'DotaznÃk je vyplnÄ?n!'
WHERE
langid = 5 AND
resource_id = 7
Note that Unicode allows all Unicode characters to be stored. The Unicode
collation affects only sorting and comparison.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
resource_id=7
When querying the updated value I get
resource_ID langID data
7 5 DotaznÃk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,|||Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02=C2=A0pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Then I update the following row into the table:
> > update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langi=d=3D5 and
> > resource_id=3D7
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data =3D N'Dotazn=C3=ADk je vypln=C4=9Bn!'
> WHERE
> =C2=A0 =C2=A0 langid =3D 5 AND
> =C2=A0 =C2=A0 resource_id =3D 7
> Note that Unicode allows all Unicode characters to be stored. =C2=A0The U=nicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid==3D5 and
> resource_id=3D7
> When querying the updated value I get
> resource_ID langID =C2=A0 =C2=A0 =C2=A0data
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5= Dotazn=C3=ADk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,|||> Only thing I wonder now, is how I could forget :-)
I'm glad I was able to help. I think you'll remember the 'N' the next time
;-)
--
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181646750.111306.272120@.z28g2000prd.googlegroups.com...
Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02 pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Then I update the following row into the table:
> > update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
> > resource_id=7
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data = N'DotaznÃk je vyplnÄ?n!'
> WHERE
> langid = 5 AND
> resource_id = 7
> Note that Unicode allows all Unicode characters to be stored. The Unicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
> resource_id=7
> When querying the updated value I get
> resource_ID langID data
> 7 5 DotaznÃk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid=3D= 5 and
resource_id=3D7
When querying the updated value I get
resource_ID langID data
7 5 Dotazn=C3=ADk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,> Then I update the following row into the table:
> update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
> resource_id=7
For a Unicode constant, prefix the literal with N:
UPDATE dbo.usr_data
SET data = N'DotaznÃk je vyplnÄ?n!'
WHERE
langid = 5 AND
resource_id = 7
Note that Unicode allows all Unicode characters to be stored. The Unicode
collation affects only sorting and comparison.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
resource_id=7
When querying the updated value I get
resource_ID langID data
7 5 DotaznÃk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,|||Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02=C2=A0pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Then I update the following row into the table:
> > update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langi=d=3D5 and
> > resource_id=3D7
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data =3D N'Dotazn=C3=ADk je vypln=C4=9Bn!'
> WHERE
> =C2=A0 =C2=A0 langid =3D 5 AND
> =C2=A0 =C2=A0 resource_id =3D 7
> Note that Unicode allows all Unicode characters to be stored. =C2=A0The U=nicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid==3D5 and
> resource_id=3D7
> When querying the updated value I get
> resource_ID langID =C2=A0 =C2=A0 =C2=A0data
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5= Dotazn=C3=ADk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,|||> Only thing I wonder now, is how I could forget :-)
I'm glad I was able to help. I think you'll remember the 'N' the next time
;-)
--
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181646750.111306.272120@.z28g2000prd.googlegroups.com...
Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02 pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Then I update the following row into the table:
> > update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
> > resource_id=7
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data = N'DotaznÃk je vyplnÄ?n!'
> WHERE
> langid = 5 AND
> resource_id = 7
> Note that Unicode allows all Unicode characters to be stored. The Unicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data='DotaznÃk je vyplnÄ?n!' where langid=5 and
> resource_id=7
> When querying the updated value I get
> resource_ID langID data
> 7 5 DotaznÃk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,
Collation issue?
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid=3D=
5 and
resource_id=3D7
When querying the updated value I get
resource_ID langID data
7 5 Dotazn=C3=ADk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,> Then I update the following row into the table:
> update usr_data set data='Dotazn_k je vyplněn!' where langid=5 and
> resource_id=7
For a Unicode constant, prefix the literal with N:
UPDATE dbo.usr_data
SET data = N'Dotazn_k je vyplněn!'
WHERE
langid = 5 AND
resource_id = 7
Note that Unicode allows all Unicode characters to be stored. The Unicode
collation affects only sorting and comparison.
Hope this helps.
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data='Dotazn_k je vyplněn!' where langid=5 and
resource_id=7
When querying the updated value I get
resource_ID langID data
7 5 Dotazn_k je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,|||Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02=C2=A0pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
d=3D5 and[vbcol=seagreen]
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data =3D N'Dotazn=C3=ADk je vypln=C4=9Bn!'
> WHERE
> =C2=A0 =C2=A0 langid =3D 5 AND
> =C2=A0 =C2=A0 resource_id =3D 7
> Note that Unicode allows all Unicode characters to be stored. =C2=A0The U=
nicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid=
=3D5 and
> resource_id=3D7
> When querying the updated value I get
> resource_ID langID =C2=A0 =C2=A0 =C2=A0data
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5=
Dotazn=C3=ADk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,|||> Only thing I wonder now, is how I could forget :-)
I'm glad I was able to help. I think you'll remember the 'N' the next time
;-)
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181646750.111306.272120@.z28g2000prd.googlegroups.com...
Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02 pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data = N'Dotazn_k je vyplněn!'
> WHERE
> langid = 5 AND
> resource_id = 7
> Note that Unicode allows all Unicode characters to be stored. The Unicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data='Dotazn_k je vyplněn!' where langid=5 and
> resource_id=7
> When querying the updated value I get
> resource_ID langID data
> 7 5 Dotazn_k je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid=3D=
5 and
resource_id=3D7
When querying the updated value I get
resource_ID langID data
7 5 Dotazn=C3=ADk je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,> Then I update the following row into the table:
> update usr_data set data='Dotazn_k je vyplněn!' where langid=5 and
> resource_id=7
For a Unicode constant, prefix the literal with N:
UPDATE dbo.usr_data
SET data = N'Dotazn_k je vyplněn!'
WHERE
langid = 5 AND
resource_id = 7
Note that Unicode allows all Unicode characters to be stored. The Unicode
collation affects only sorting and comparison.
Hope this helps.
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
Hi,
I am having problems querying some czech letters (or maybe it is
inserting that fails?).
Here is the deal:
We have a web application that supports different languages. We have
stored the different messages to be displayed into a nvarchar column
with the SQL_Danish_Pref_CP1_CI_AS collation.
resource_ID
int
langID
int
data nvarchar(4000 )
Then I update the following row into the table:
update usr_data set data='Dotazn_k je vyplněn!' where langid=5 and
resource_id=7
When querying the updated value I get
resource_ID langID data
7 5 Dotazn_k je vyplnen!
See the missing upside-down ^ over the letter e in the last word.
I have also tested this on collation Latin1_General_CI_AS and
Czech_CI_AS with the same result.
I created a new table with a nvarchar column with the above collation
and inserted the same text, but the result was the same.
What am I missing here?
Thanks,|||Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02=C2=A0pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
d=3D5 and[vbcol=seagreen]
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data =3D N'Dotazn=C3=ADk je vypln=C4=9Bn!'
> WHERE
> =C2=A0 =C2=A0 langid =3D 5 AND
> =C2=A0 =C2=A0 resource_id =3D 7
> Note that Unicode allows all Unicode characters to be stored. =C2=A0The U=
nicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data=3D'Dotazn=C3=ADk je vypln=C4=9Bn!' where langid=
=3D5 and
> resource_id=3D7
> When querying the updated value I get
> resource_ID langID =C2=A0 =C2=A0 =C2=A0data
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5=
Dotazn=C3=ADk je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,|||> Only thing I wonder now, is how I could forget :-)
I'm glad I was able to help. I think you'll remember the 'N' the next time
;-)
Dan Guzman
SQL Server MVP
"gurbao" <audunj@.gmail.com> wrote in message
news:1181646750.111306.272120@.z28g2000prd.googlegroups.com...
Thanks a lot!
That did the trick.
Only thing I wonder now, is how I could forget :-)
Regards,
On Jun 12, 1:02 pm, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> For a Unicode constant, prefix the literal with N:
> UPDATE dbo.usr_data
> SET data = N'Dotazn_k je vyplněn!'
> WHERE
> langid = 5 AND
> resource_id = 7
> Note that Unicode allows all Unicode characters to be stored. The Unicode
> collation affects only sorting and comparison.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "gurbao" <aud...@.gmail.com> wrote in message
> news:1181645527.452234.163220@.x35g2000prf.googlegroups.com...
> Hi,
> I am having problems querying some czech letters (or maybe it is
> inserting that fails?).
> Here is the deal:
> We have a web application that supports different languages. We have
> stored the different messages to be displayed into a nvarchar column
> with the SQL_Danish_Pref_CP1_CI_AS collation.
> resource_ID
> int
> langID
> int
> data nvarchar(4000 )
> Then I update the following row into the table:
> update usr_data set data='Dotazn_k je vyplněn!' where langid=5 and
> resource_id=7
> When querying the updated value I get
> resource_ID langID data
> 7 5 Dotazn_k je vyplnen!
> See the missing upside-down ^ over the letter e in the last word.
> I have also tested this on collation Latin1_General_CI_AS and
> Czech_CI_AS with the same result.
> I created a new table with a nvarchar column with the above collation
> and inserted the same text, but the result was the same.
> What am I missing here?
> Thanks,
Thursday, March 22, 2012
Collation conflict isssue
Hi,
The tempdb db is having different collation than the application db.
I rebuilt the master db with the appropriate collation after backing up
master, model, msdb, appln databases.
On restore of the databases (master, model, msdb, appln) from the backup
restores the backed up database collation.
Is there any idea to restore the db with different collation than the
backed up collation.
Thanks,
*** Sent via Developersdex http://www.developersdex.com ***John Jayaseelan (john.jayaseelan@.caravan-club.co.uk) writes:
> The tempdb db is having different collation than the application db.
> I rebuilt the master db with the appropriate collation after backing up
> master, model, msdb, appln databases.
> On restore of the databases (master, model, msdb, appln) from the backup
> restores the backed up database collation.
> Is there any idea to restore the db with different collation than the
> backed up collation.
The only way to change the collation of a database, is to bulk out
all data, and rebuild the database from scripts. Well, you could
alter the collation of all character columns, but that would require
you to drop indexes and constraints, so that would probably be more work.
The same applies to the system databases. Rather than restoring backups
of these, you should have entered the information by other means.
Another option may be to install a second instance with a matching
collation.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
Collation Conflict Error 368 (I think)
We just upgraded an instance of SQL Server 2000 to SQL Server 2005. When using our application to login, we are receiving an error 368, which refers to a collation conflict. Has anyone seen this?
I'm moving your thread to the database engine forum, where it may get more attention.
Paul
|||Run the profiler to see which statement your application is issuing against the database. Are you sure you are using the same collation on the new server than on the old one ? Normally this happens if you are comparing two different collation with each other (like in joins or equal expressions).
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
Unfortunately, only this message got moved for those of us using NNTP. Any chance that when you move a thread, you can mention where the thread was moved *from*, so we can see it? That will certainly increase the chance that it gets more attention after being moved. Steve Kass Drew University Paul Nicholson - MSFT@.discussions.microsoft.com wrote:
> I'm moving your thread to the database engine forum, where it may get
> more attention.
>
> Paul
>
>
collation conflict
Hi, all
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
Elizabeta
Elizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>
|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
[vbcol=seagreen]
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
ening.
>
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
Elizabeta
Elizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>
|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
[vbcol=seagreen]
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
ening.
>
collation conflict
Hi, all
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
> >Hi, all
> >
> >I am doing testing of my application, actualy one Store Procedure at the moment.
> >
> >I have development database.
> >
> >I copy tables that I need for the testing.
> >
> >The same queries that run on live database fail here wth the message
> >'cannot resolve collation conflict...'
> >
> >I discovered that it is due to all copied tables have other collation in char columns.
> >
> >When I change them to database default setting, the stored procedure works OK.
> >
> >My question is:
> >
> >how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
> >
> >I am very grateful for any helpful information.
> >
> >TIA
> >
> >Elizabeta
> >
> >
>
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
> >Hi, all
> >
> >I am doing testing of my application, actualy one Store Procedure at the moment.
> >
> >I have development database.
> >
> >I copy tables that I need for the testing.
> >
> >The same queries that run on live database fail here wth the message
> >'cannot resolve collation conflict...'
> >
> >I discovered that it is due to all copied tables have other collation in char columns.
> >
> >When I change them to database default setting, the stored procedure works OK.
> >
> >My question is:
> >
> >how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
> >
> >I am very grateful for any helpful information.
> >
> >TIA
> >
> >Elizabeta
> >
> >
>
collation conflict
Hi, all
I am doing testing of my application, actualy one Store Procedure at the mo
ment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in cha
r columns.
When I change them to database default setting, the stored procedure works O
K.
My question is:
how can I avoid to have collation in new copied tables, although the databas
es have it the same. I tried to copy using CREATE TABLE scripts or DTS servi
ces, copy as objects, always the same problem. Is there any setting on SQL s
erver to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the m
oment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in ch
ar columns.
>When I change them to database default setting, the stored procedure works
OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have
it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as ob
jects, always the same problem. Is there any setting on SQL server to avoid this hap
pen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "scri
pt
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
>
ening.[vbcol=seagreen]
>sqlsql
I am doing testing of my application, actualy one Store Procedure at the mo
ment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in cha
r columns.
When I change them to database default setting, the stored procedure works O
K.
My question is:
how can I avoid to have collation in new copied tables, although the databas
es have it the same. I tried to copy using CREATE TABLE scripts or DTS servi
ces, copy as objects, always the same problem. Is there any setting on SQL s
erver to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the m
oment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in ch
ar columns.
>When I change them to database default setting, the stored procedure works
OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have
it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as ob
jects, always the same problem. Is there any setting on SQL server to avoid this hap
pen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "scri
pt
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
>
ening.[vbcol=seagreen]
>sqlsql
collation & compatibility issues
1) how to check the colllation settings on SQL 7 ?
2) I have 2 SQL Srv - SQL7 and SQL2000.
A client application does the following:
- retrieves data from SQL2000 to the SQL7 for queries.
- data updated in SQL7 is also periodically syn with the SQL2000 srv.
there is no direct user acess with the tables, all is interfaced thru the
client app. So must the SQL Server 2000 compatibility settings (under server
properties) be changed to 7.0 ?
Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
SQL2000 from being accessed by other app.
The WAIT TYPE is usually networkIO for the blocking connection from SQL7 to
SQL2000.
So I suspect could it be collation settings or some other in-compatibility
between the 2 SQL Servers.
>
> 1) how to check the collation settings on SQL 7 ?
The error log will tell you this information.
> 2) I have 2 SQL Srv - SQL7 and SQL2000.
> A client application does the following:
> - retrieves data from SQL2000 to the SQL7 for queries.
> - data updated in SQL7 is also periodically syn with the SQL2000 srv.
> there is no direct user acess with the tables, all is interfaced thru the
> client app. So must the SQL Server 2000 compatibility settings (under
server
> properties) be changed to 7.0 ?
> Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
> SQL2000 from being accessed by other app.
> The WAIT TYPE is usually networkIO for the blocking connection from SQL7
to
> SQL2000.
> So I suspect could it be collation settings or some other in-compatibility
> between the 2 SQL Servers.
You should run a blocker script to identify the top of blocking chains. The
script from this article might help:
INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Regards,
Eric Crdenas
SQL Server senior support professional
2) I have 2 SQL Srv - SQL7 and SQL2000.
A client application does the following:
- retrieves data from SQL2000 to the SQL7 for queries.
- data updated in SQL7 is also periodically syn with the SQL2000 srv.
there is no direct user acess with the tables, all is interfaced thru the
client app. So must the SQL Server 2000 compatibility settings (under server
properties) be changed to 7.0 ?
Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
SQL2000 from being accessed by other app.
The WAIT TYPE is usually networkIO for the blocking connection from SQL7 to
SQL2000.
So I suspect could it be collation settings or some other in-compatibility
between the 2 SQL Servers.
>
> 1) how to check the collation settings on SQL 7 ?
The error log will tell you this information.
> 2) I have 2 SQL Srv - SQL7 and SQL2000.
> A client application does the following:
> - retrieves data from SQL2000 to the SQL7 for queries.
> - data updated in SQL7 is also periodically syn with the SQL2000 srv.
> there is no direct user acess with the tables, all is interfaced thru the
> client app. So must the SQL Server 2000 compatibility settings (under
server
> properties) be changed to 7.0 ?
> Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
> SQL2000 from being accessed by other app.
> The WAIT TYPE is usually networkIO for the blocking connection from SQL7
to
> SQL2000.
> So I suspect could it be collation settings or some other in-compatibility
> between the 2 SQL Servers.
You should run a blocker script to identify the top of blocking chains. The
script from this article might help:
INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Regards,
Eric Crdenas
SQL Server senior support professional
collation & compatibility issues
1) how to check the colllation settings on SQL 7 ?
2) I have 2 SQL Srv - SQL7 and SQL2000.
A client application does the following:
- retrieves data from SQL2000 to the SQL7 for queries.
- data updated in SQL7 is also periodically syn with the SQL2000 srv.
there is no direct user acess with the tables, all is interfaced thru the
client app. So must the SQL Server 2000 compatibility settings (under server
properties) be changed to 7.0 ?
Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
SQL2000 from being accessed by other app.
The WAIT TYPE is usually networkIO for the blocking connection from SQL7 to
SQL2000.
So I suspect could it be collation settings or some other in-compatibility
between the 2 SQL Servers.>
> 1) how to check the collation settings on SQL 7 ?
--
The error log will tell you this information.
> 2) I have 2 SQL Srv - SQL7 and SQL2000.
> A client application does the following:
> - retrieves data from SQL2000 to the SQL7 for queries.
> - data updated in SQL7 is also periodically syn with the SQL2000 srv.
> there is no direct user acess with the tables, all is interfaced thru the
> client app. So must the SQL Server 2000 compatibility settings (under
server
> properties) be changed to 7.0 ?
> Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
> SQL2000 from being accessed by other app.
> The WAIT TYPE is usually networkIO for the blocking connection from SQL7
to
> SQL2000.
> So I suspect could it be collation settings or some other in-compatibility
> between the 2 SQL Servers.
--
You should run a blocker script to identify the top of blocking chains. The
script from this article might help:
INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Regards,
Eric Crdenas
SQL Server senior support professional
2) I have 2 SQL Srv - SQL7 and SQL2000.
A client application does the following:
- retrieves data from SQL2000 to the SQL7 for queries.
- data updated in SQL7 is also periodically syn with the SQL2000 srv.
there is no direct user acess with the tables, all is interfaced thru the
client app. So must the SQL Server 2000 compatibility settings (under server
properties) be changed to 7.0 ?
Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
SQL2000 from being accessed by other app.
The WAIT TYPE is usually networkIO for the blocking connection from SQL7 to
SQL2000.
So I suspect could it be collation settings or some other in-compatibility
between the 2 SQL Servers.>
> 1) how to check the collation settings on SQL 7 ?
--
The error log will tell you this information.
> 2) I have 2 SQL Srv - SQL7 and SQL2000.
> A client application does the following:
> - retrieves data from SQL2000 to the SQL7 for queries.
> - data updated in SQL7 is also periodically syn with the SQL2000 srv.
> there is no direct user acess with the tables, all is interfaced thru the
> client app. So must the SQL Server 2000 compatibility settings (under
server
> properties) be changed to 7.0 ?
> Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
> SQL2000 from being accessed by other app.
> The WAIT TYPE is usually networkIO for the blocking connection from SQL7
to
> SQL2000.
> So I suspect could it be collation settings or some other in-compatibility
> between the 2 SQL Servers.
--
You should run a blocker script to identify the top of blocking chains. The
script from this article might help:
INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Regards,
Eric Crdenas
SQL Server senior support professional
Tuesday, March 20, 2012
collation & compatibility issues
1) how to check the colllation settings on SQL 7 ?
2) I have 2 SQL Srv - SQL7 and SQL2000.
A client application does the following:
- retrieves data from SQL2000 to the SQL7 for queries.
- data updated in SQL7 is also periodically syn with the SQL2000 srv.
there is no direct user acess with the tables, all is interfaced thru the
client app. So must the SQL Server 2000 compatibility settings (under server
properties) be changed to 7.0 ?
Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
SQL2000 from being accessed by other app.
The WAIT TYPE is usually networkIO for the blocking connection from SQL7 to
SQL2000.
So I suspect could it be collation settings or some other in-compatibility
between the 2 SQL Servers.>
> 1) how to check the collation settings on SQL 7 ?
--
The error log will tell you this information.
> 2) I have 2 SQL Srv - SQL7 and SQL2000.
> A client application does the following:
> - retrieves data from SQL2000 to the SQL7 for queries.
> - data updated in SQL7 is also periodically syn with the SQL2000 srv.
> there is no direct user acess with the tables, all is interfaced thru the
> client app. So must the SQL Server 2000 compatibility settings (under
server
> properties) be changed to 7.0 ?
> Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
> SQL2000 from being accessed by other app.
> The WAIT TYPE is usually networkIO for the blocking connection from SQL7
to
> SQL2000.
> So I suspect could it be collation settings or some other in-compatibility
> between the 2 SQL Servers.
--
You should run a blocker script to identify the top of blocking chains. The
script from this article might help:
INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Regards,
--
Eric Cárdenas
SQL Server senior support professional
2) I have 2 SQL Srv - SQL7 and SQL2000.
A client application does the following:
- retrieves data from SQL2000 to the SQL7 for queries.
- data updated in SQL7 is also periodically syn with the SQL2000 srv.
there is no direct user acess with the tables, all is interfaced thru the
client app. So must the SQL Server 2000 compatibility settings (under server
properties) be changed to 7.0 ?
Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
SQL2000 from being accessed by other app.
The WAIT TYPE is usually networkIO for the blocking connection from SQL7 to
SQL2000.
So I suspect could it be collation settings or some other in-compatibility
between the 2 SQL Servers.>
> 1) how to check the collation settings on SQL 7 ?
--
The error log will tell you this information.
> 2) I have 2 SQL Srv - SQL7 and SQL2000.
> A client application does the following:
> - retrieves data from SQL2000 to the SQL7 for queries.
> - data updated in SQL7 is also periodically syn with the SQL2000 srv.
> there is no direct user acess with the tables, all is interfaced thru the
> client app. So must the SQL Server 2000 compatibility settings (under
server
> properties) be changed to 7.0 ?
> Problem is there is frequent blocking on SQL2000 by SQL7, preventing the
> SQL2000 from being accessed by other app.
> The WAIT TYPE is usually networkIO for the blocking connection from SQL7
to
> SQL2000.
> So I suspect could it be collation settings or some other in-compatibility
> between the 2 SQL Servers.
--
You should run a blocker script to identify the top of blocking chains. The
script from this article might help:
INF: How to Monitor SQL Server 2000 Blocking
http://support.microsoft.com/?id=271509
Regards,
--
Eric Cárdenas
SQL Server senior support professional
Collation
I'm rebuilding an application server and am trying to figure out how I can
get the right collation as what my old server has. I haven't installed SQL
Server in quite a while, and this is my first time installing SQL Server 2005
and it's a lot different.
The collation on my old server is SQL_Latin1_General_CP1_Cl_AS how does that
equate to all the SQL Collations I have to choose from? The default is
dictionary order, case-insensitive, for use with 1252 Character Set.
I'm not sure what the CP1_Cl_AS means. Does anyone know what I need to
choose in order to get the right collation? If memory serves me correctly
changing this after the fact isn't recommended (this was SQL 2000).Hi Penny,
This is from BOL:
Codepage
Specifies a one- to four-digit number that identifies the code page used by
the collation. CP1 specifies code page 1252, for all other code pages the
complete code page number is specified. For example, CP1251 specifies code
page 1251 and CP850 specifies code page 850.
CaseSensitivity
CI specifies case-insensitive, CS specifies case-sensitive.
AccentSensitivity
AI specifies accent-insensitive, AS specifies accent-sensitive.
Source:
http://msdn2.microsoft.com/en-us/library/ms180175.aspx
In your case, If you want collation compatibility then you must go with CP
1252 (Because CP1 = Code Page 1252), Case Intensive (CI), Accent Sensetive
(AS).
Note:
Latin1_general use CP 1252
Ekrem Ã?nsoy
"Penny" <Penny@.discussions.microsoft.com> wrote in message
news:DD3B734B-8436-4EED-89E5-CD3E31DC960A@.microsoft.com...
> I'm rebuilding an application server and am trying to figure out how I can
> get the right collation as what my old server has. I haven't installed
> SQL
> Server in quite a while, and this is my first time installing SQL Server
> 2005
> and it's a lot different.
> The collation on my old server is SQL_Latin1_General_CP1_Cl_AS how does
> that
> equate to all the SQL Collations I have to choose from? The default is
> dictionary order, case-insensitive, for use with 1252 Character Set.
> I'm not sure what the CP1_Cl_AS means. Does anyone know what I need to
> choose in order to get the right collation? If memory serves me correctly
> changing this after the fact isn't recommended (this was SQL 2000).
>
get the right collation as what my old server has. I haven't installed SQL
Server in quite a while, and this is my first time installing SQL Server 2005
and it's a lot different.
The collation on my old server is SQL_Latin1_General_CP1_Cl_AS how does that
equate to all the SQL Collations I have to choose from? The default is
dictionary order, case-insensitive, for use with 1252 Character Set.
I'm not sure what the CP1_Cl_AS means. Does anyone know what I need to
choose in order to get the right collation? If memory serves me correctly
changing this after the fact isn't recommended (this was SQL 2000).Hi Penny,
This is from BOL:
Codepage
Specifies a one- to four-digit number that identifies the code page used by
the collation. CP1 specifies code page 1252, for all other code pages the
complete code page number is specified. For example, CP1251 specifies code
page 1251 and CP850 specifies code page 850.
CaseSensitivity
CI specifies case-insensitive, CS specifies case-sensitive.
AccentSensitivity
AI specifies accent-insensitive, AS specifies accent-sensitive.
Source:
http://msdn2.microsoft.com/en-us/library/ms180175.aspx
In your case, If you want collation compatibility then you must go with CP
1252 (Because CP1 = Code Page 1252), Case Intensive (CI), Accent Sensetive
(AS).
Note:
Latin1_general use CP 1252
Ekrem Ã?nsoy
"Penny" <Penny@.discussions.microsoft.com> wrote in message
news:DD3B734B-8436-4EED-89E5-CD3E31DC960A@.microsoft.com...
> I'm rebuilding an application server and am trying to figure out how I can
> get the right collation as what my old server has. I haven't installed
> SQL
> Server in quite a while, and this is my first time installing SQL Server
> 2005
> and it's a lot different.
> The collation on my old server is SQL_Latin1_General_CP1_Cl_AS how does
> that
> equate to all the SQL Collations I have to choose from? The default is
> dictionary order, case-insensitive, for use with 1252 Character Set.
> I'm not sure what the CP1_Cl_AS means. Does anyone know what I need to
> choose in order to get the right collation? If memory serves me correctly
> changing this after the fact isn't recommended (this was SQL 2000).
>
Monday, March 19, 2012
Coldfusion Web appls from Oracle to SQL Server 2005 - How to use Application Roles in Coldfusion
Coldfusion Web appls from Oracle to SQL Server 2005 - How to use Application Roles in Coldfusion.
Is there anyone who has used application roles in Coldfusion Applications? How would you set this up?
I know how to set up application roles. If you establish your application role and you move from one page to another, how would you run cfquery since you loose your initial user connection in place of the application role connection. Are there alternatives to using application roles in Coldfusion?
Sample code would be helpful.
TF
There's not enough information here to help you - are you talking about SQL Server's application roles alone or how they interact from Oracle or Coldfusion? For general info, check here:
http://msdn2.microsoft.com/en-us/library/ms190998(SQL.90).aspx
|||I want to find out how to use SQL Server 2005 application roles using Coldfusion MX as the application. I know how to use application role using a non-web based application. I do not know the issues involved with application roles using a web based application. We use Coldfusion to develop Web applications and we are wanting to use SQL Server 2005 as our database. We have to determine how our application security will work and we thought we could use application roles.
TF.|||SEe this http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_18684&sliceId=1 is any use.Cold Fusion 6.1 point to 64-bit SQL 2005
Hi guys, I want to know whether Cold Fusion 6.1 supports on 64-bit server? My web application server is 32-bit with Cold Fusion 6.1 and my SQL server is running 64-bit (SQL Server 2005). Is there any problem if I set a data source to the SQL server ? Does anyone experience that before using Cold Fusion? Hope can get a reply here asap. Thanks alot.
Best Regards,
Hans
There is no difference connecting to a 32bit vs a 64bit SQL server. The differences are all internal to the SQL server.Sunday, March 11, 2012
Coexisting SQL Reader & UPDATE
In my current application, I have an administration form that fills in labels and checked states via data entered into the database using a similar user input field. What the admin page does is it first lists all the record names in a listview, then on select, it fills in the form based on what the records contain. This means labels text change, and check states change based on the string "True" or "False". This was done using the SQL Reader command.
Within the same form, the read checkboxes are editable via the admin. When the admin edits the controls, he will click the update button at the bottom and the database will UPDATE .. WHERE UserName = (Scalar for ListBox1.SelectedValue)
I've used the exact same UPDATE command in my form for the user, except the only difference was @. the WHERE clause-- I had it updating based on a GUID. I know my SQL statement is correct, but it just won't update the data.
Is it possible that the READER, which starts (and closes) on pageload cannot coexist within the same form as the UPDATE code?
My code is incredibly long, so for the purposes of a short post I'm not including any bit of it-- but if you would like to see it, just let me know.
Why do you need to use a GUID? Why not use an identity integer primary key? Update will then be a simple stored procedure and a bit of wrapper code.
|||I thought that too, but the GUID's working fine on the other pages-- thats not what I have a problem with. I'm modifying an existing structure, and if the GUID scheme works, I'd rather not make more work for myself.
On the form in question, GUID doesn't even exist as an instance on it. ListBox1.SelectedValue is what I'm trying to get as my WHERE arguement-- and it does pass, no errors generated, but the form does not update.
|||When you run it in debug mode with your breakpoints set, where does it stop at? When you click update does it call to execute your sql statement?
|||when I set breakpoints, I have it set at the NonQuery, and everything inputs correctly: my SQL statement is properly formed down to the ListBox selected value translating into an EXISTING column name (eg, Current user is Test, Test is databound to listbox. Test's data is displayed, modified, then "updated". Break. SQL statement reads 'UPDATE Login SET ... WHERE UserName = 'Test', properly formed and existing), the ExecuteNonQuery goes through, there are no errors generated. and the redirect coded after the update processes. Display test's data again, and no changes were made.
|||Figured it out.
I made two functions, "ReadMe()" and "UpdateMe()", and called them on load and on button click. However, although all my statements were correct, ButtonClick calls a postback, and with the reader executing onpostback, the database automatically rolled back the variables.
Solution: I changed the ReadMe() function to execute on ListBox1.SelectedIndex changed, and the update was successful.
Whoops!
Co-Existence of MSDE Instances
My server has an instance of MSDE that was installed by the VERITAS backup
software.I have a new application now thats to be deployed which will need
MSDE,Is it ok to load another instance of MSDE for the new application or can
I use the one instance to run both VERITAS and the New application...any
suggestions will be much appreciated.
Thank you all.
hi Maverick,
"maverick" <maverick@.discussions.microsoft.com> ha scritto nel messaggio
news:2239EDC1-15D6-4F6E-B0DC-093D5199D97E@.microsoft.com...
> My server has an instance of MSDE that was installed by the VERITAS backup
> software.I have a new application now thats to be deployed which will need
> MSDE,Is it ok to load another instance of MSDE for the new application or
can
> I use the one instance to run both VERITAS and the New application...any
> suggestions will be much appreciated.
> Thank you all.
as you already know, technically you can install up to 16 MSDE/SQL Server
instances on the same server... only 1 instance can be the default
instances, where all others will be named instances..
legally, it's all another story.
since MSDE has become rellay free, the original constraint that each ISV
MUST install his/her own instance has become obsolete, but....
but each ISV can legally protect his/her own installed instance so that it
can not be used by other applications/external databases
so you have to check Verits documentation or directly ask them for such an
info
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||You don't really want to share another application's instance anyway. What
is the SA password they are using? Even if you are granted access (which I
doubt), what happens when the software is updated and they replace the
database or you uninstall the application and the database (and the MSDE)
instance is removed?
No, you really should install your own instance until we get to SQL Express
which does suggest/encourage use of a common instance.
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:2q2sltFqoea4U1@.uni-berlin.de...
> hi Maverick,
> "maverick" <maverick@.discussions.microsoft.com> ha scritto nel messaggio
> news:2239EDC1-15D6-4F6E-B0DC-093D5199D97E@.microsoft.com...
> can
> as you already know, technically you can install up to 16 MSDE/SQL Server
> instances on the same server... only 1 instance can be the default
> instances, where all others will be named instances..
> legally, it's all another story.
> since MSDE has become rellay free, the original constraint that each ISV
> MUST install his/her own instance has become obsolete, but....
> but each ISV can legally protect his/her own installed instance so that it
> can not be used by other applications/external databases
> so you have to check Verits documentation or directly ask them for such an
> info
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
|||Well, it worked for me. I installed the MSCRM Outlook Sales client on my
laptop. It installs MSDE for it's database.
They I installed Microsoft Small business Manager which will also create a
MSDE database.
It worked and the machine did not complain too much.
But beyond that I did not do much.
Also this worked with full SqL and MSDE on the same laptop.
MSDE supported Sales Outlook Client for MSCRM and I had the Great Plains 7.5
running and connecting the client to the full MSSQL Databases.
I slowed the laptop down but that was about it.
Hope that helps.
"maverick" wrote:
> My server has an instance of MSDE that was installed by the VERITAS backup
> software.I have a new application now thats to be deployed which will need
> MSDE,Is it ok to load another instance of MSDE for the new application or can
> I use the one instance to run both VERITAS and the New application...any
> suggestions will be much appreciated.
> Thank you all.
|||With the MSDE, you are encouraged to run your application in its own
instance. This also avoids issues with administrative passwords, etc. In the
future (with SQL Express), the situation changes though and you'll be
encouraged to use the single SQLExpress instance.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Curt Spanburgh" <CurtSpanburgh@.discussions.microsoft.com> wrote in message
news:D42533B2-F027-40F4-B2B8-E05E3299857F@.microsoft.com...
> Well, it worked for me. I installed the MSCRM Outlook Sales client on my
> laptop. It installs MSDE for it's database.
> They I installed Microsoft Small business Manager which will also create a
> MSDE database.
> It worked and the machine did not complain too much.
> But beyond that I did not do much.
> Also this worked with full SqL and MSDE on the same laptop.
> MSDE supported Sales Outlook Client for MSCRM and I had the Great Plains
7.5[vbcol=seagreen]
> running and connecting the client to the full MSSQL Databases.
> I slowed the laptop down but that was about it.
> Hope that helps.
>
> "maverick" wrote:
backup[vbcol=seagreen]
need[vbcol=seagreen]
or can[vbcol=seagreen]
software.I have a new application now thats to be deployed which will need
MSDE,Is it ok to load another instance of MSDE for the new application or can
I use the one instance to run both VERITAS and the New application...any
suggestions will be much appreciated.
Thank you all.
hi Maverick,
"maverick" <maverick@.discussions.microsoft.com> ha scritto nel messaggio
news:2239EDC1-15D6-4F6E-B0DC-093D5199D97E@.microsoft.com...
> My server has an instance of MSDE that was installed by the VERITAS backup
> software.I have a new application now thats to be deployed which will need
> MSDE,Is it ok to load another instance of MSDE for the new application or
can
> I use the one instance to run both VERITAS and the New application...any
> suggestions will be much appreciated.
> Thank you all.
as you already know, technically you can install up to 16 MSDE/SQL Server
instances on the same server... only 1 instance can be the default
instances, where all others will be named instances..
legally, it's all another story.
since MSDE has become rellay free, the original constraint that each ISV
MUST install his/her own instance has become obsolete, but....
but each ISV can legally protect his/her own installed instance so that it
can not be used by other applications/external databases
so you have to check Verits documentation or directly ask them for such an
info
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||You don't really want to share another application's instance anyway. What
is the SA password they are using? Even if you are granted access (which I
doubt), what happens when the software is updated and they replace the
database or you uninstall the application and the database (and the MSDE)
instance is removed?
No, you really should install your own instance until we get to SQL Express
which does suggest/encourage use of a common instance.
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:2q2sltFqoea4U1@.uni-berlin.de...
> hi Maverick,
> "maverick" <maverick@.discussions.microsoft.com> ha scritto nel messaggio
> news:2239EDC1-15D6-4F6E-B0DC-093D5199D97E@.microsoft.com...
> can
> as you already know, technically you can install up to 16 MSDE/SQL Server
> instances on the same server... only 1 instance can be the default
> instances, where all others will be named instances..
> legally, it's all another story.
> since MSDE has become rellay free, the original constraint that each ISV
> MUST install his/her own instance has become obsolete, but....
> but each ISV can legally protect his/her own installed instance so that it
> can not be used by other applications/external databases
> so you have to check Verits documentation or directly ask them for such an
> info
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
|||Well, it worked for me. I installed the MSCRM Outlook Sales client on my
laptop. It installs MSDE for it's database.
They I installed Microsoft Small business Manager which will also create a
MSDE database.
It worked and the machine did not complain too much.
But beyond that I did not do much.
Also this worked with full SqL and MSDE on the same laptop.
MSDE supported Sales Outlook Client for MSCRM and I had the Great Plains 7.5
running and connecting the client to the full MSSQL Databases.
I slowed the laptop down but that was about it.
Hope that helps.
"maverick" wrote:
> My server has an instance of MSDE that was installed by the VERITAS backup
> software.I have a new application now thats to be deployed which will need
> MSDE,Is it ok to load another instance of MSDE for the new application or can
> I use the one instance to run both VERITAS and the New application...any
> suggestions will be much appreciated.
> Thank you all.
|||With the MSDE, you are encouraged to run your application in its own
instance. This also avoids issues with administrative passwords, etc. In the
future (with SQL Express), the situation changes though and you'll be
encouraged to use the single SQLExpress instance.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Curt Spanburgh" <CurtSpanburgh@.discussions.microsoft.com> wrote in message
news:D42533B2-F027-40F4-B2B8-E05E3299857F@.microsoft.com...
> Well, it worked for me. I installed the MSCRM Outlook Sales client on my
> laptop. It installs MSDE for it's database.
> They I installed Microsoft Small business Manager which will also create a
> MSDE database.
> It worked and the machine did not complain too much.
> But beyond that I did not do much.
> Also this worked with full SqL and MSDE on the same laptop.
> MSDE supported Sales Outlook Client for MSCRM and I had the Great Plains
7.5[vbcol=seagreen]
> running and connecting the client to the full MSSQL Databases.
> I slowed the laptop down but that was about it.
> Hope that helps.
>
> "maverick" wrote:
backup[vbcol=seagreen]
need[vbcol=seagreen]
or can[vbcol=seagreen]
CodeAssist Err:35602 Key is not unique in collection
hi
i use CodeAssist application from Shredian Company.
its good application to make VB/SQL Code from any Database (Code Generator).
but now when i connect to SQL2000 Database by ODBC and open any table in
database i have this error:
35602 Key is not unique in collection
any one know why? or how i can solve this problem?
if someone have code generator application like codeAssist please tell me.
--
Tarek M. SialaHi ,
I found the following article for the cause of this error Err:35602 Key is
not unique in collection. Hope it help
POTENTIAL CAUSES :
1. The Integrity Wizard has been run on a database that has already
completed the Integrity Checks.
Resolution - Delete the Integrity Wizard Upgrade tables from the Application
database directory.
CORRECTION STEPS:
1. Using Explorer locate and delete the following .DAT files from the
Application database directory:
DATECHECK.DAT DATECKERR.DAT INTCKFLOW.DAT
Sylvana Mounir
Devloper Support Engineer
Micorosft MEA Developer Support Center
"Tark Siala" <tarksiala@.icc-libya.com> wrote in message
news:e3nO5cIbGHA.2372@.TK2MSFTNGP03.phx.gbl...
> hi
> i use CodeAssist application from Shredian Company.
> its good application to make VB/SQL Code from any Database (Code
> Generator).
> but now when i connect to SQL2000 Database by ODBC and open any table in
> database i have this error:
> 35602 Key is not unique in collection
> any one know why? or how i can solve this problem?
> if someone have code generator application like codeAssist please tell me.
> --
> Tarek M. Siala
>|||Some times is better to buy books and learn how to write the code from your
self. You save lot of money and time
Need more help? Search the web http://search.elakbar.net
"Tark Siala" <tarksiala@.icc-libya.com> wrote in message news:e3nO5cIbGHA.237
2@.TK2MSFTNGP03.phx.gbl...
hi
i use CodeAssist application from Shredian Company.
its good application to make VB/SQL Code from any Database (Code Generator).
but now when i connect to SQL2000 Database by ODBC and open any table in
database i have this error:
35602 Key is not unique in collection
any one know why? or how i can solve this problem?
if someone have code generator application like codeAssist please tell me.
--
Tarek M. Siala
i use CodeAssist application from Shredian Company.
its good application to make VB/SQL Code from any Database (Code Generator).
but now when i connect to SQL2000 Database by ODBC and open any table in
database i have this error:
35602 Key is not unique in collection
any one know why? or how i can solve this problem?
if someone have code generator application like codeAssist please tell me.
--
Tarek M. SialaHi ,
I found the following article for the cause of this error Err:35602 Key is
not unique in collection. Hope it help
POTENTIAL CAUSES :
1. The Integrity Wizard has been run on a database that has already
completed the Integrity Checks.
Resolution - Delete the Integrity Wizard Upgrade tables from the Application
database directory.
CORRECTION STEPS:
1. Using Explorer locate and delete the following .DAT files from the
Application database directory:
DATECHECK.DAT DATECKERR.DAT INTCKFLOW.DAT
Sylvana Mounir
Devloper Support Engineer
Micorosft MEA Developer Support Center
"Tark Siala" <tarksiala@.icc-libya.com> wrote in message
news:e3nO5cIbGHA.2372@.TK2MSFTNGP03.phx.gbl...
> hi
> i use CodeAssist application from Shredian Company.
> its good application to make VB/SQL Code from any Database (Code
> Generator).
> but now when i connect to SQL2000 Database by ODBC and open any table in
> database i have this error:
> 35602 Key is not unique in collection
> any one know why? or how i can solve this problem?
> if someone have code generator application like codeAssist please tell me.
> --
> Tarek M. Siala
>|||Some times is better to buy books and learn how to write the code from your
self. You save lot of money and time
Need more help? Search the web http://search.elakbar.net
"Tark Siala" <tarksiala@.icc-libya.com> wrote in message news:e3nO5cIbGHA.237
2@.TK2MSFTNGP03.phx.gbl...
hi
i use CodeAssist application from Shredian Company.
its good application to make VB/SQL Code from any Database (Code Generator).
but now when i connect to SQL2000 Database by ODBC and open any table in
database i have this error:
35602 Key is not unique in collection
any one know why? or how i can solve this problem?
if someone have code generator application like codeAssist please tell me.
--
Tarek M. Siala
Wednesday, March 7, 2012
Cocurrency
In a web application I am receiving following error message while trying to do the same database query from multiple sessions simultaneouslly. "The Connection is already open (state = connecting)." This only happens for simultaneous hits. Is it a common scenario of cocurrency or I am getting something unusual here? If its a common issue what should be the workaround?
TIA
Hemangyou should NEVER be trying to share an established connection.
each user/request should create its own connection object for accessing the db.|||Hi,
I already took care of not sharring the connection.
Anyways I found where the error was. It was just a programming error somewhere along the lines, it was nothing related to concurrency but i found it while testing it and so i missunderstood that. I fixed that up. Thanks for your interest and prompt reply.
Hemang
cobol -> SQL2005
I'm not "cobol person" but now, I have to bind a cobol application (from mainframe) to query SQL 2005
Have somebody had this task?No, but it should be pretty straightforward... All of the mini / mainframe products I've seen use ODBC to allow native applications running on the host (the mini or the mainframe) to bind to the PC database. Operative word being "should", this should be quite straightforward, simply changing the ODBC driver referenced and setting the server / database / security settings appropriately.
-PatP|||No, but it should be pretty straightforward... All of the mini / mainframe products I've seen use ODBC to allow native applications running on the host (the mini or the mainframe) to bind to the PC database. Operative word being "should", this should be quite straightforward, simply changing the ODBC driver referenced and setting the server / database / security settings appropriately.
-PatP
Thanks Pat
I try to find communication between Mainframe and PC db throgh ODBC :).
This cobol-programm never have been running to bind to the PC db - it is working with mainframe DB2. This is tamporary deal (we are going from DB2-to SQL2005) I could write this from PC using VS C# for example and hit mainframe, but I have to save even interface of this "stupid" programm :).
thanks again|||how about "Connect Direct" or "Direct Connect" ?|||wath do you mean?
Actually, now I'm studing how to do this for IBM CICS environment that uses EXEC SQL CONNECT to DB2 to change to SQL2005
Have somebody had this task?No, but it should be pretty straightforward... All of the mini / mainframe products I've seen use ODBC to allow native applications running on the host (the mini or the mainframe) to bind to the PC database. Operative word being "should", this should be quite straightforward, simply changing the ODBC driver referenced and setting the server / database / security settings appropriately.
-PatP|||No, but it should be pretty straightforward... All of the mini / mainframe products I've seen use ODBC to allow native applications running on the host (the mini or the mainframe) to bind to the PC database. Operative word being "should", this should be quite straightforward, simply changing the ODBC driver referenced and setting the server / database / security settings appropriately.
-PatP
Thanks Pat
I try to find communication between Mainframe and PC db throgh ODBC :).
This cobol-programm never have been running to bind to the PC db - it is working with mainframe DB2. This is tamporary deal (we are going from DB2-to SQL2005) I could write this from PC using VS C# for example and hit mainframe, but I have to save even interface of this "stupid" programm :).
thanks again|||how about "Connect Direct" or "Direct Connect" ?|||wath do you mean?
Actually, now I'm studing how to do this for IBM CICS environment that uses EXEC SQL CONNECT to DB2 to change to SQL2005
Friday, February 24, 2012
Clustering SQL Server with four 2-way, or two 4-way?
This depends on your SQL Instance and application architecture. If you are running more than 2 SQL Instances with high load on each then you may go with a 4-node cluster and run an active/active/active/active configuration which will give you a higher le
vel of availability (more than one node can fail and you are still in business, howbeit with higher response times). Be careful about comparing model x with 2 processors with model y with 4 processors. Also, say you have 16GB of RAM for one application o
n on 4-CPU node it will allow you to use AWE and improve performance on a "busy" node. This is of almost no benefit when running a 2-CPU node with say 4GB as you're pretty much stuck with the 2.7GB limit per SQL Instance (assuming you have /PAE /3G switc
hes enabled).
I'd [almost] always go for the 4P 16GB 2-node config over the 2P 4/8GB 4-node config. But it really depend on how many high-load SQL Instances you have and what level of server redundancy you need. If you are considering 2P nodes you probably have relat
ively light SQL load - which may also sway your decision.
Yes and no. With 4 proc machines, you have 2 more processors to use than
with 2 proc machines. BUT, it depends upon your application whether you
will get better performance or throughput. If you have massive DSS queries
running and parallelism turned on full blast, the 4 proc machine will
probably only get you marginally better performance since the DSS queries
will monopolize the processors. If you are running an OLTP style
application, you will be much better throughput on the 4 proc machine than
you will on the 2 proc machine.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
vel of availability (more than one node can fail and you are still in business, howbeit with higher response times). Be careful about comparing model x with 2 processors with model y with 4 processors. Also, say you have 16GB of RAM for one application o
n on 4-CPU node it will allow you to use AWE and improve performance on a "busy" node. This is of almost no benefit when running a 2-CPU node with say 4GB as you're pretty much stuck with the 2.7GB limit per SQL Instance (assuming you have /PAE /3G switc
hes enabled).
I'd [almost] always go for the 4P 16GB 2-node config over the 2P 4/8GB 4-node config. But it really depend on how many high-load SQL Instances you have and what level of server redundancy you need. If you are considering 2P nodes you probably have relat
ively light SQL load - which may also sway your decision.
Yes and no. With 4 proc machines, you have 2 more processors to use than
with 2 proc machines. BUT, it depends upon your application whether you
will get better performance or throughput. If you have massive DSS queries
running and parallelism turned on full blast, the 4 proc machine will
probably only get you marginally better performance since the DSS queries
will monopolize the processors. If you are running an OLTP style
application, you will be much better throughput on the 4 proc machine than
you will on the 2 proc machine.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
Subscribe to:
Posts (Atom)