Bookmark and Share

Notice: On March 31, it was announced that Statalist is moving from an email list to a forum. The old list will shut down on April 23, and its replacement, is already up and running.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: st: odbc load a large table, hitting max obs limit

From   tashi lama <>
To   <>
Subject   RE: st: odbc load a large table, hitting max obs limit
Date   Fri, 7 Sep 2012 14:18:30 +0000

Thank you very much. I do think that more than it pollutes the archives, it enriches it provided the questions are closely related and not silly. And as it appears, the issue seems very technical (stata's inability to take string of indeterminate length and storing in fixed length while using odbc) and I am sure anyone using odbc to get data from databases would encounter such problems.  Now the good thing, the person whoever has a problem with odbc can see all without turning into different threads. Thanks again. 
> Date: Thu, 6 Sep 2012 14:31:30 -0700
> Subject: Re: st: odbc load a large table, hitting max obs limit
> From:
> To:
> Tashi,
> You should not use another thread to ask your related questions. It's
> distracting and messes up the archiving.
> However, I am feeling nice today, so I am going to violate that rule.
> You need to recast the varchar variable as something that Stata can
> understand. This should look like this:
> odbc load, exec("select readership_id read_date cast(doc_title as
> char(244)) from readership;") dsn("indigo") sqlshow
> compress
> Loosely, varchar is a string of indeterminate length. This format is
> useful when you have strings of very different length, so storing them
> as a fixed length string is inefficient. Stata does not allow such
> luxuries, so I am converting doc_title to a 244 character string, but
> compressing after to something shorter. If you pick something too
> short, like char(1), SQL might complain that you're truncating it on
> the right. 244 is the limit in Stata, so if your doc_titles are ever
> longer, you will need to split that variable into 2 or more manageable
> variables using SQL. If you can't figure how to do that with the help
> of Dr. Google, try asking at Statalist is
> not the best place for such queries.
> *
> * For searches and help try:
> *
> *
> * 		 	   		  
*   For searches and help try:

© Copyright 1996–2016 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   Site index