Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Wrong numeric field size from SQLEXEC() call
Message
De
14/12/2005 17:59:44
 
 
À
14/12/2005 15:00:36
Information générale
Forum:
Visual FoxPro
Catégorie:
Client/serveur
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Divers
Thread ID:
01077250
Message ID:
01078080
Vues:
38
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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform