SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Page 1 of 2 12 LastLast
Results 1 to 10 of 14
  1. #1
    Advanced Member
    Join Date
    Oct 1999
    Location
    Chicago, IL
    Posts
    652
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    Have you ever run that INSERT command against a SQL Server database outside of SilkTest?

    What happens when you try executing that SQL command through one of SQL Server's tools like Enterprise Manager or isqlw command-line util? I don't think they use ODBC, so just trying to take ODBC out of the picture to see if it's really the culprit.

    I don't have any unicode experience, but have done some non-unicode SQL Server queries, etc.

    [ 03-06-2006, 01:57 PM: Message edited by: Brian ]

  2. #2
    Super Member
    Join Date
    Jul 2001
    Location
    Earth
    Posts
    1,882
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    running the same query through ODBC in other tools gives the same response. The issue appears to be the ODBC driver.

  3. #3
    Super Member
    Join Date
    Jul 2001
    Location
    Earth
    Posts
    1,882
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Access vs. SQLServer

    OK...I'd like to hear from some DB experts out there. I'd got a script that does this in SilkTest International:

    </font><blockquote><font size="1" face="Verdana, Arial, Helvetica">code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> [ ] sSqlCommand=&quot;INSERT INTO TestTable (sName) VALUES ('&amp;#21776;&amp;#20808;&amp;#29983;');&quot; // can't get real chinese chars to display in this post.
    [ ] //Execute SQL
    [ ] hBuffer = DB_ExecuteSql(hDataBase,sSqlCommand) </pre><hr /></blockquote><font size="2" face="Verdana, Arial, Helvetica">When the code executes on an Access DB all works as expected...The unicode name is put into the table and things are happy. Now when we try to execute this on a SQLServer 8.0 database where the column is of data type ntext (to handle unicode chars) and when the script runs all that gets inserted in the table is a "???" instead of the "唐先生" that I expect and get from Access. I don't get any errors from ODBC...it lets the SQL execute, it just munges the data in the process.

    I am using version 2000.85.1117.00 of the SQL Server ODBC driver (MDAC 2.8).

    It appears to me that this is an ODBC configuration issue, but I haven't been able to figure this one out. Any DB Experts out there that might know what to do to make this work right?

    [ 03-06-2006, 12:38 PM: Message edited by: jamesso ]

  4. #4
    Advanced Member
    Join Date
    Oct 1999
    Location
    Chicago, IL
    Posts
    652
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    What about through a DB-Library tool like isql?

  5. #5
    Senior Member
    Join Date
    Oct 2002
    Location
    England
    Posts
    368
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    Hmm. A few things spring to mind but if you are trying to get Chinese chars into your db, I'd want to know the following:

    a) What code page is your server configured for?
    b) In your ODBC definition do you have Perform translation of character data checked?
    c) What code page is your client configured for?

    You say you're using SQLServer v8. I take it actually mean SQL Server 2000?

    There are quite a few things that could be happening here. Like it might actually be getting onto the database correctly (client -&gt; db works fine) but not being translated when you do a select or view the data (db -&gt; client doesn't translate).

    Perhaps a good starting point is http://support.microsoft.com/?scid=h...748%2fen-us%2f and take it from there.

    Regards
    Peat

  6. #6
    Super Member
    Join Date
    Jul 2001
    Location
    Earth
    Posts
    1,882
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    Thanks Peat -- Well the client is a webpage that displays 8 different languages. UTF-8 is the encoding used on the web pages. Basically I'm getting information in unicode from a web page and trying to write the text into a DB for results purposes. SilkTest is reading in the characters OK, but when passing them into the DB they all show up as question marks for Chinese, Japanese and Korean characters.

    If I try passing the same characters to an Access DB the characters work great....trying to pass them to SQLServer 2000 is where the problems start. This tells me that the ODBC driver isn't doing something that that the MSAccess ODBC driver is doing.

  7. #7
    Junior Member
    Join Date
    Nov 2004
    Location
    Cleveland, Ohio
    Posts
    18
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    Just out of curiousity what is the default language for the user that you are using to login to the database?
    William Watkins
    Senior Software QA Engineer
    Intuit Real Estate Solutions

    20800 Harvard Road * Cleveland, OH 44122
    Tel 216.825.6525 * Fax 216.750.1144
    William_Watkins@intuit.com| | www.realestate.intuit.com

  8. #8
    Super Member
    Join Date
    Jul 2001
    Location
    Earth
    Posts
    1,882
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    English

  9. #9
    Junior Member
    Join Date
    Nov 2004
    Location
    Cleveland, Ohio
    Posts
    18
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    Not sure if this will help at all but maybe try and chnage the default language for the user to the language that you are working with.
    William Watkins
    Senior Software QA Engineer
    Intuit Real Estate Solutions

    20800 Harvard Road * Cleveland, OH 44122
    Tel 216.825.6525 * Fax 216.750.1144
    William_Watkins@intuit.com| | www.realestate.intuit.com

  10. #10
    Super Member
    Join Date
    Jul 2001
    Location
    Earth
    Posts
    1,882
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Access vs. SQLServer

    Nope...didn't help. Is there anyone out there that uses ODBC to put unicode characters (Chinese, Japanese, or Korean) into SQLServer?

 

 
Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 10.00%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 12:36 AM.

Copyright BetaSoft Inc.