ODBC to iSeries - Blank Values

[wtgee via AccessMonster.com]

I have an ODBC connection to some iSeries tables that I am building an Access 2000 front-end application for. Everything is almost working fine except...

I have some fields in the iSeries that have a length of 255 and when I link to that table via ODBC, it pulls down 255 blank characters (or whatever text I have entered plus blank characters filled in to 255). As a result, I cannot type anything new in the field unless I have my Insert (Overwrite) button turned on or if I delete the entire (blank) contents of the field and then start writing. If it were me I wouldn't mind but this will be deployed to 20+ people and I know they will forget to turn on their insert key each time.

Is there a way around this problem?

Thanks,
wtgee

 

[Rick Brandt]

I have an ODBC connection to some iSeries tables that I am building an Access
2000 front-end application for. Everything is almost working fine except...

I have some fields in the iSeries that have a length of 255 and when I link to
that table via ODBC, it pulls down 255 blank characters (or whatever text I
have entered plus blank characters filled in to 255). As a result, I cannot
type anything new in the field unless I have my Insert (Overwrite) button
turned on or if I delete the entire (blank) contents of the field and then
start writing. If it were me I wouldn't mind but this will be deployed to 20+
people and I know they will forget to turn on their insert key each time.

Is there a way around this problem?

This happens anytime a Char DataType is used instead of a VarChar. It's not
real easy to work around generally. You could have an unbound TextBox that is
placed behind the bound one and have your Tab Sequence take you to the unbound
one where you have copied the entry from the bound control. In the AfterUpdate
of the unbound one, copy the entry to the bound one. Easy to do for one
control, but a pain if you have to do it everywhere.

I've tried setting the text to the Trim() value in certain events, but that
dirties the record in many situations where you otherwise wouldn't so it's not a
great solution.

 

[wtgee via AccessMonster.com]

Yeah, I tried playing with some Trim() but couldn't get it to work how I wanted. The fake text box is a good idea but I agree that it might just be a big pain (there are easily 100 fields).

So if the table is switched to a VarChar would that solve the problem? This is a new table they are creating so it is not a problem to change that at this point.

Thanks,
wtgee

 

[Rick Brandt]

Yeah, I tried playing with some Trim() but couldn't get it to work how I
wanted. The fake text box is a good idea but I agree that it might just be a
big pain (there are easily 100 fields).

So if the table is switched to a VarChar would that solve the problem? This
is a new table they are creating so it is not a problem to change that at this
point.

Yes, if you have any control over that have them changed to VarChars and the
issue immediately goes away.