Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: st: -odbc- and VARCHAR() [was odbc load a large table, hitting max obs limit]
From
tashi lama <[email protected]>
To
<[email protected]>
Subject
RE: st: -odbc- and VARCHAR() [was odbc load a large table, hitting max obs limit]
Date
Mon, 10 Sep 2012 13:52:48 +0000
I think it has something to do with the operating system. I didn't have any problem loading columns with type varchar while using centos 5.8. It all of sudden skipped those columns when I jumped to centos 6.3. As Dimitriy suggested, casting varchar to fixed length string would do the magic.
Thanks,
Tashi
----------------------------------------
> From: [email protected]
> To: [email protected]
> Subject: st: -odbc- and VARCHAR() [was odbc load a large table, hitting max obs limit]
> Date: Mon, 10 Sep 2012 11:22:15 +0900
>
> Dimitriy V. Masterov wrote (excerpted):
>
> You need to recast the varchar variable as something that Stata can understand.
>
> --------------------------------------------------------------------------------
>
> Is that peculiar to MySQL or Unix ODBC drivers or something? I've never had any
> problems with Stata and VARCHAR() column data types in MS SQL Server databases,
> or even MS Access, for that matter. Rows of VARCHAR() columns containing text
> longer than 244 characters get automatically truncated, and those Unicode
> characters in NVARCHAR() columns that cannot be coerced into ANSI become
> question marks, but [N]VARCHAR() columns are otherwise read-in without any
> problem.
>
> Joseph Coveney
>
>
> *
> * For searches and help try:
> * http://www.stata.com/help.cgi?search
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/