Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Wrong numeric field size from SQLEXEC() call
Message
From
14/12/2005 17:59:44
 
 
To
14/12/2005 15:00:36
General information
Forum:
Visual FoxPro
Category:
Client/server
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Miscellaneous
Thread ID:
01077250
Message ID:
01078080
Views:
34
Hello,

"I tried to map single column:
...
LOCAL loca as CursorAdapter
LOCA = CREATEOBJECT('cursoradapter')
loca.DataSource= nconnh
loca.DataSourceType ="ODBC"
loCA.SelectCmd = csql
loCA.CursorSchema = 'foo N(1)'
loCA.CursorFill(.t.)
BROWSE
but got No table is oper error in browse command. CursorSchema requires that ALL columns are specified.
I have select statements with a lot of columns and creating schemas for all columns in all selects is a huge meaningless work.
I want to specify N(1) types for 1-2 columns only. Any idea ? Maybe some conversion function can be specified ?"

Oh, I forgot that one has to specify all columns, a bit annoying.
I once wrote a little script that build the cursorschema.
i haven't have it at hand, but it's something like this:
FUNCTION MakeCursorSchema(lnCon,lcSQL)
LOCAL laFields[1], lcSchema, lnFields, xj
lcSchema = ""
IF SQLEXEC(lnCon,lcSQL,'tempcursor') = 1
 lnFields = AFIELDS(laFields,'tempcursor')
 FOR xj = 1 TO lnFields
  lcSchema = lcSchema + IIF(xj>1,',','') + laFields[xj,1] + " " + ;
  laFields[xj,2]

  DO CASE
   CASE laFields[xj,2] = 'C' OR laFields[xj,2] = 'V' OR laFields[xj,2] = 'Q'
    lcSchema = lcSchema + "(" + ALLTRIM(STR(laFields[xj,3])) + ")"
   CASE laFields[xj,2] = 'N' 
    lcSchema = lcSchema + "(" + ALLTRIM(STR(laFields[xj,3])) + ;
    IIF(laFields[xj,4]>0,"," + ALLTRIM(STR(laFields[xj,4])),"") + ")"
   CASE ... && implement other types
  ENDCASE
    
 ENDFOR
ENDIF
RETURN lcSchema
ENDFUNC
than you can easily build the cursorschema from the command window
_cliptext = MakeCursorSchema(yourconnection,'SELECT ..')
and paste it into your code, this would at least save you a lot of typing.

"This is really weird. Is the only way to fix this to check every numeric field in every record at upsize time, as Fabio suggests?"

it depends, are these values valid? if so you have to make the postgres column wider, otherwise you probably should find a way that these invalid values aren't stored in the dbf in the first place. I always tackle problems from their source, and if these values aren't valid the problem is that they are somehow getting stored. If you solve it like this you don't have to deal with these kind of consecutive faults.

Regards
Christian
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform