I hope you corrected the wiki if you found any mistakes :-) It's
basically a write-up of what I did (and still do when I need to validate

The verbose HS.UPDATE.FILEINFO doesn't catch problems with individual
files - it lets you know if it's fallen over and left a load of files
unprocessed - that caught us badly :-(

I'm guessing from the error that you might have a load of spaces or
other invisible crud in field 3! You could try deleting it and typing it
in again. I think I've known that work ...

Step one - make sure all the i-types have been compiled.
step two - if that doesn't work, delete all the itypes and see if the
file appears okay
step three - if that doesn't work, scream and shout! Otherwise, add the
itypes back one by one, making sure they're compiled, that you can list
them from tcl, etc etc.

I've never used just plain "varchar", so I haven't direct experience of
what you've done. And you might try removing the itypes just from
@SELECT rather than from the DICT. That might work, and might make
eliminating the problem easier.

The other thing - can you export the problem file directly? I think
we've had problems where the trans'd (or whatever) file had the problem

When you get odbc problems, they're a sod, aren't they :-) I think
you're going to have to just logically eliminate every possibility one
by one. Use this email list copiously to make sure you understand what
you're doing, then write the problem up and add it to the wiki :-) 


-----Original Message-----
On Behalf Of John Hester
Sent: 17 February 2004 21:09
To: U2 Users Discussion List
Subject: Re: Enabling ODBC for non-SQL file

Anthony Youngman wrote:
> Have you put the correct SQL type definitions in fields 8?
> Did HS.UPDATE.FILEINFO actually work correctly! THAT'S A BIGGIE!
> I've shoved a little article on pickwiki you might want to look at -
> multivaluedatabases>universe>odbcaccess
> Cheers,
> Wol

Thanks for pointing me to the pickwiki.  That was a lot easier to follow

than the UV documentation.  I made sure the correct SQL types were in 
attr. 8 of all the dict items.  I had previously cleared the entire dict

and put in only the things I needed (I copied the live file to a 
separate ODBC-only account), so I only have a handful to worry about.  I

also manually added the file to HS_FILE_ACCESS.  I used the verbose 
version of HS.UPDATE.FILEINFO from the wicki and there were no 
complaints about this particular file.  Still can't get this file to be 
seen though.  HS.SCRUB does give an error message on all the I-type dict

items and I'm not sure exactly what it's telling me.  I get this

CUST.CITY was analyzed using VARCHAR(254) for a data type
* Invalid conversion code '                   '.

And here's the I-type:

0001: I
0002: TRANS(CR,@ID[8,8],21,"X")
0004: CITY
0005: 20L
0006: S

The I-type is referencing a file that's a Q-pointer to a non-SQL file in

another account.  All the other I-types it complains about point to the 
same file.  The only other potential problem I can think of is since I'm

using a stripped down version of the actual dict, there are attributes 
in the data portion that now have no corresponding dict entry.  Could 
this be a problem?


u2-users mailing list


This transmission is intended for the named recipient only. It may contain private and 
confidential information. If this has come to you in error you must not act on 
anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, 
or show it to anyone. Please e-mail the sender to inform us of the transmission error 
or telephone ECA International immediately and delete the e-mail from your information 

Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong 
Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.


u2-users mailing list

Reply via email to