On Fri, 11 Mar 2011, Riccardo (Jack) Lucchetti wrote: > On Fri, 11 Mar 2011, Leon Unger wrote: > > > recently I tried to read in several series via odbc including one dummy > > series and I forgot to change its entries > > from "No" and "YES" to "0" and "1". > > However, SQL retrieved for all series the correct number of observations. > > BUT ALL SERIES were corrupted. > > That's why two thoughts come up: > > > > 1) I know from importing STATA files that GRETL changes string entries to > > number entries. Does GRETL use > > information > > provided by the STATA file, or does it this job by itself? If yes, would it > > be possible to add this functionality > > to the odbc read in process? > > > > 2) If one has always to provide numerical entries and e.g. one series is > > not correcltly specified then actually > > only this series should be corrupted. > > Of course everything is doable with enough time and resources. I also > agree that automagic conversion of stuff coming from an ODBC connection > would be very cool. However, the development of gretl is something that > very few people do in their spare time. I don't mean to be rude, but > asking the user to put a little extra care in formulating an SQL query > doesn't sound unreasonable to me (especially considering that the user did > not have to pay a single penny for the program).
Basically I agree with Jack, with one reservation: that is, the attempt "blindly" to treat a string variable as if it were a floating-point value would be likely to crash gretl (although apparently that didn't happen in this particular case). And crashing is always a bad policy. So even if we don't do an automagical conversion of string-valued ODBC variables we should at least flag an error and quit in this sort of case. I'll see what we can do about that. Allin Cottrell
