Tweet
I am trying to attach an MS Access link table, linked to a PF, to an Access form. The PF is defined with all fields ALWNULL & DFT(*NULL). Access seems to think that each field is padded by blanks - I can't go to the 'end' of the text and start keying without using the insert key (changing to overstrike mode or whatever it's called) or deleting the invisible blanks first. When I populated the PF with an append query I tried using trim(fldnam) with no change in the result. Here's what I don't understand. If I view the PF on the AS/400 with either DBU or DSPPFM (hex mode) I do indeed see the blanks padding the field on the right. But if I add a record via MS Access, I still see the hex 40s in the field yet Access thinks the field ends with the non blank character. Can there be something in that field that I can't see in hex mode with DSPPFM? Has anyone had a similar experience?
-
-
MS Access linked to PF - padded with blanks???
Tom, I can't answer your explicit question, but just offer a workaround. What if you code, for each necessary field, inside the "got_focus" subroutine (sorry, I don't know Access' true subroutine name), a fldvalue = trimr(fldvalue)? This would change the field's value to be that value with all trailing blanks removed. Bill -
MS Access linked to PF - padded with blanks???
Bill - It sounded like a possibility but so far no dice. And I was wrong about everything being fine if Access updated the record. (I couldn't accept that there was something in that field that I can't see in hex mode.) Access remembers temporarily. If you close it down and open it up again the problem resurfaces - Access doesn't want to insert into a field that's padded with blanks.Comment
-
MS Access linked to PF - padded with blanks???
I hit this problem in our project. We ended up training the users to be aware of the trailing blanks and delete them first, if they wanted to insert. My understanding is that DB2/400 pads these fields when it stores the data. If I had access to an AS/400 now, though, I'd try defining all this sort of character fields in DDS as varying, setting the max size to the current data field's length, and try again. I believe that this might take care of the trailing blanks/padding issue, but I haven't personally done it (next time).Comment
-
MS Access linked to PF - padded with blanks???
I never did find a way around the blank padding. If it becomes an issue we're considering using Bill Robbins' idea: Private Sub fldnam_GotFocus() If Len(RTrim(fldnam)) > 0 Then fldnam.SelStart = Len(RTrim(fldnam)) fldnam.SelLength = Len(fldnam) - Len(RTrim(fldnam)) End If End Sub The blanks are still there but Access starts out ready to key over them as soon as you enter the field. I did try the variable length field (for other reasons.) It doesn't solve the trailing blank problem but it does come into Access as a memo data type which is something I need. It also allows me to use the existing memo fields without wasting much space. Most of them have next to nothing in them, then you find one where someone wrote a novel. As I read the documentation, the data only occupies the varlen value until it goes over. A FIELD1 1000A VARLEN(50) Then the space expands to the maximum when it goes over. In my example when the field has more than 50 characters it occupies 1000 bytes of space or so. From my testing is appears to be true. (Sorry to be such an anachronism but DDS isn't dead yet in southern Ohio.) It must go on behind the scenes because every mechanism I know of for looking at the file shows a 1000 (actually 1002) field.Comment
Comment