CRLF in Query

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

Guest

I need to run an update query in Access 2003 and use the VBcrlf to insert a
new line within a memo field.

update tableA set fieldA = "8/10/2005 - add a new comment at the top" &
vbcrlf & vbcrlf & fieldA

when it runs it thinks that vbcrlf is a parameter and prompts me for it...

what am I doing wrong?

any help would be appreciated..thank you!
 
I need to run an update query in Access 2003 and use the VBcrlf to insert a
new line within a memo field.

update tableA set fieldA = "8/10/2005 - add a new comment at the top" &
vbcrlf & vbcrlf & fieldA

when it runs it thinks that vbcrlf is a parameter and prompts me for it...

what am I doing wrong?

any help would be appreciated..thank you!

As far as I know, that should work. But you might try this instead of
vbCrLf:

[stuff] & Chr$(13) & Chr$(10) & [more stuff]
 
You'll need to use the Chr() function instead of the VB function.
update tableA set fieldA = "8/10/2005 - add a new comment at the top" &
Chr(13) & Chr(10) & Chr(13) & Chr(10) & fieldA

Perhaps this is splitting hairs; me being a perfectionist; me being a
religious code-biggot, but...

Chr(...) returns a Variant.
Chr$(...) returns a String.

Variants are evil. Variants hate you. Variants should be outlawed.

1. Anything of the Variant data type is guaranteed to be slow an inefficient
because underneath the covers, the system has to do lots of type checking to
try to guess what the data type of the value really is.

2. Anything of the Variant data type can be null. Concatenate that to a
string or try to store one in a column that disallows nulls will kill your
code.

3. Lookup the storage size of the Variant data type in the help file.
Variants are fat and huge.

It comes down to a simple math problem:

Slow
Error Prone
+ Memory Hog
----------------------
= Evil Satanic Hatred that wants to kill your app.

Any time I have to use a VB or VBA function that has a xxx() sig and also a
xxx$() sig, I *ALWAYS* use the one with the $ on it because I know I'll get
a type-safe result that won't explode.

No offense intended.
 
BTW, I'm not so sure that the difference makes a difference any more.
Current documentation for Access 2003 says, "The Chr function in Microsoft
Access always returns 2-byte characters. In previous versions of Microsoft
Access, Chr(&H41) and ChrB(&H41) were equal, but in the current version of
Microsoft Access, Chr(&H41) and ChrB(&H41) + ChrB(0) are equal." If you
search for Chr$() in MSDN it only returns hits for Chr().

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html
 
Back
Top