Text Field Woes

[shannonp]

I have a table with multiple text fields. Each one is set to 50 text string characters long (the default). The weird thing is that with some (not all) of the text fields no matter how long the actual text values are, 'Access' decides to add space characters to the end. For instance...

Lets say I enter a value into say [Field1] of:

"abc"

Once I lose focus from [Field1] in datasheet view I found that when I go back to it that that it has been appended with 47 spaces. So the actual value of [Field1] is:

"abc "
(I think thats 47 spaces!?)

This seems very quirky to me and is a hassle when performing string comparisons; I keep having to use the Trim() function to ensure my code works as I intended it to. Is there something I am missing? A simple field to toggle perhaps?? I thought that maybe I accidentally entered spaces in by mistake but after maticulous attempts to ammend it....I gave up!

In any event, I would appreciate if anyone out there can solve my frustrating dilemma.


Shann

 

[RickSpr]

This is very strange indeed. In a text box control or a datasheet cell, Access always deletes any trailing spaces on input. Are you sure it's not that some code is later appending the spaces? This certainly isn't normal Acces behavior. This is plain old table datasheet, right?

The only ways I know of to make Access store "trailing" spaces are (1) to store the value in code, or (2) to use a non-graphic character, particularly a NULL (binary 0) character after the spaces. In the latter case it only looks like there are trailing spaces.

But you can't accidentally enter a NULL character from the keyboard, so if this isn't happening in code and is happening without closing the datasheet, I can't explain it.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[shannonp]

Thanks for the response Rick.

It is indeed just a regular table and viewed in regular datasheet style.

I can also confirm that there is no rogue vb code being executed.

Shall I call Bill Gates (are we allowed to say his name on here?!? LOL) and tell him he has a gremlin in his system.


Shann

 

[shannonp]

OH!?!....

This may not have any impact on the issue.....but in this table I have about 128 fields (don't ask why! ) and its only until after it reaches the 86th field that this is occuring.

What is the actually capability of an individual table, or more to the point....how many fields can it hold before problems start occuring? BUT, about 10 fields after the affected ones are functioning correctly

Cheers


Shann

 

[RickSpr]

Look in the help file under "specifications" for the limit of fields per table. For Access 2000, it's 255. There is, of course, no specification for "number of fields per table without random malfunctions".

I would say you have likely found a bug. Have you checked the Microsoft Knowledge Base to see if such a bug has been reported? (msdn.microsoft.com)

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[src23]

Hi.. I'm not sure that I could help you solve your problem though I'll be glad to try, but - if you're interested - I'd like to 'trade' with you another strange database of mine - you give me a 'mostra' , and I'll give you mine. My database 'gives birth' to some nasty query-creatures, named like "TmprryQryFrLnkFldsCrtn0123456789". And it also doesn't want to change a RowSource of a combo in a subform, from another subform - although it should've done it without problem (damn it - stubborn Access!!!!).


What dou you say ? Deal ? In case YES, how can we send/receive the databases ? Using mail ?