string quotes syntax

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

having a senior moment...

Dim Temp As Variant

This works OnExit of Main form control:

Me.SubForm.Form!TextBox = Me.Number

This does Not work:

Me.SubForm.Form!TextBox = Me.Text

no error - just nothing returned to the subform TextBox

Have tried to wrap with ""

Me.SubForm.Form!TextBox = "Me.Text"
returned literally: Me.Text
Me.SubForm.Form!TextBox = "&Me.Text&"
returned literally: &Me.Text&

Dim to String didn't change anything
tried "'" but threw an error while in vb...
(double single double)

what the heck ?
 
NetworkTrade said:
having a senior moment...

Dim Temp As Variant

This works OnExit of Main form control:

Me.SubForm.Form!TextBox = Me.Number

This does Not work:

Me.SubForm.Form!TextBox = Me.Text

no error - just nothing returned to the subform TextBox []
Dim to String didn't change anything
tried "'" but threw an error while in vb...
(double single double)

what the heck ?
Click to expand...


Syntactically, bothe are fine.

Since the Temp variable is not used, it doesn't matter what
it's type is.

You should tell us what Text and Number represent, text
boxes on your form, variables in your code, or ???. Note
that both of those words (along with many, many others) are
reserved words and using them can cause confusion for both
you and Access.
 
wasn't a senior moment...
something more serious was at fault....I think possibly the table field name
was one of the reserved words....Cycle
haven't had time to look it up....

but got an overflow error doing a sanity check of attempt to put text into
the box in the form...and there wasn't any data type mismatch...

went to the table and rebuilt with a different/new field name...and now
works....

Me.SubForm.Form!TextBox = Me.Text
 
NetworkTrade said:
wasn't a senior moment...
something more serious was at fault....I think possibly the table field name
was one of the reserved words....Cycle
haven't had time to look it up....

but got an overflow error doing a sanity check of attempt to put text into
the box in the form...and there wasn't any data type mismatch...

went to the table and rebuilt with a different/new field name...and now
works....

Me.SubForm.Form!TextBox = Me.Text
Click to expand...


As I said before, change the other names too.
 
thanks, did not see your earlier reply.

My example of: Me.SubForm.Form!TextBox = Me.Number

is an attempt to keep the question very short....the actual control names
are not those...

but the non working field/control name was: cycle (datatype text)

In debug; I attempted with vb just to put in some text into its textbox on a
form - really simple - and it threw an overflow error which I very rarely
ever see.... so something was clearly wrong with trying to use this
field/control.

Renaming it at the table has seemed to completely resolve this problem.
 
NetworkTrade said:
thanks, did not see your earlier reply.

My example of: Me.SubForm.Form!TextBox = Me.Number

is an attempt to keep the question very short....the actual control names
are not those...

but the non working field/control name was: cycle (datatype text)

In debug; I attempted with vb just to put in some text into its textbox on a
form - really simple - and it threw an overflow error which I very rarely
ever see.... so something was clearly wrong with trying to use this
field/control.

Renaming it at the table has seemed to completely resolve this problem.
Click to expand...


Forms have a Cycle property, so if a text box is named Cycle
a reference like Me.Cycle is going to caouse trouble. I
also have a vague idea that Cycle might be an SQL keyword.

Bottom line is that there are a ton of ordinary words that
are reserved in Access/SQL/Jet/... See
http://allenbrowne.com/AppIssueBadWord.html

A fairly safe way to avoid the issue is to never use a real
word as the name of anything.
 
yes, I think I will print that list and tape it to my wall....but it is tough
because these applications are often started by lay-people....which is the
draw of Access in particular. We need to pass the word along to MS that
reserving such common words is problematic...(especially "Date")....
 
draw of Access in particular. We need to pass the word along to MS that
reserving such common words is problematic...(especially "Date")....
Click to expand...

Uh - reserved words are reserved because they need to be reserved.
Usually they are part of SQL syntax as Access is a clever UI flung
over an SQL engine.

One approach taken in Access 2007 is to force a rejection of reserved
words as Fieldnames at Table Design Time.

Ananda
 
that's definitely one approach - and it would be comprehensive...

but far easier is to avoid common layperson words.... like Date

most all of the vb reserved begin with vbxxxxxx and most of the Access
reserved words begin with acxxxxxx and this simple idea makes very
improbable that a layperson will use the word...

but to reserve normal common words like Date, Field, Cycle, Text....these
are terms used in businesses all the time - it would simpler for MS to change
to acDate or rDate or something like that....though your idea is far better
if the application warned you up front at table design....
 
Back
Top