Results 1 to 11 of 11
  1. #1
    Join Date
    May 2008
    Location
    Raleigh, NC
    Posts
    151

    Unanswered: String$ versus String

    Just being curious...I seen various functions where the '$' is appended and I don't know what difference it makes. I don't see anything in the online help so I thought I'd try the wizards here.

    Any thoughts?

    Thanx, Stu
    --If its free, take it for what its worth!

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    the $ functions return a string datatype as opposed to a variant datatype
    there is more overhead in handling varinats than string
    so there is a theoretical performance gain by using the $ functions.
    whether you will notice that in use is a different matter
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    You've apparently been looking at some fairly old code! The String$ construct is a holdover from very early (pre-Visual Basic) Basic, where the dollar sign denoted a string object/variable, as Healdem has noted. It's still recognized by VBA in order to maintain backwards compatibility, and the theoretical performance gain is just that, theoretical, assuming you're running a box purchased in this century!
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  4. #4
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    sorry Missinglinq - gotta disagree.

    blah$(someString) runs about twice as fast as blah(someString) when operating on strings and where blah is one of Left, Right, Mid (i have not personally tested other blah() functions with/out $)

    your "this century box" comment sounds slick, but writing slower-than-necessary code needs justification in any century.
    how much does it cost to add the single '$' character beyond a little self-discipline?

    sure you can fix the performance of almost anything by throwing horsepower at it, but the late Colin Chapman's "add lightness" concept somehow seems more elegant.

    izy
    currently using SS 2008R2

  5. #5
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Disagreeing is your right, of course, but you're full of it! If it really made any difference, you'd see it used all the time, here and on the other half dozen forums I frequent. The only time you ever see it, is in a post just like this, where someone has seen it somewhere and wonders what it means!
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  6. #6
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    no there is a misconception I suspect
    appending a $ to a VARIABLE is part of the original BASIC specification, appending the $ to a function was microsofts way of explciitly returning a string value from certain (not all functions)
    these days it would be a (well its always been a) lazy programmer who didn't DIM their variable to the correct datatype.. using variants is a bad technique , unless you have to use variants
    the function$ is in VBA & VB, but not VB.NET where it has been assigned tot he scrap heap becuase .NET uses a different run time that ovelraods the operators.

    I'd agree that used occasionally omitting the string function isn't going to save a huge amount of time

    but used in a tight loop with many calls to function$ can save significant time. to use it all the time seems to me like good practise.
    I'd rather be riding on the Tiger 800 or the Norton

  7. #7
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Just a note on the use dim XX as variant versus dim XX as integer (or string, etc..). (not related to the $ issue in the topic above.) But I don't think dim as a variant is necessarily always a bad technique.

    I will often dim XX as variant versus dim XX as integer. Reason - if I dim XX as integer (say for an autonumber field), I found that if I dim XX as integer, I will sometimes get an error (when it comes to large values). I'm guessing if I dim XX as double, it will probably work and that is the "ideal" way to dim it. But to avoid having to troubleshoot, dim XX as variant seems to resolve most problems (where dim as a string or dim as integer may cause issues, dim as variant does not.) I'm guessing there will be many objections to doing this but I also found that dim XX as a variant (providing the overall code is designed correctly), causes little problems with overhead. Again, I'm guessing many will disagree but this causes little problems for me with overhead or other issues so I just stick with dim XX as variant (don't get me wrong though, I will use dim as integer or dim as string where appropriate). I do this often and again, have had little problems with "overhead" or other issues.

    It may not be "ideal" to always dim XX as variant. But again, it causes very little issues for me using a variant versus a string or integer and less troubleshooting on whether the dim type is causing the issue (providing again, I reuse variable names.) Not "technically" always correct, but it works and my apps which have several dim XX as variant (and I try to use the same variable name each time), have never had overhead issues. I think if I were to always use a different variable name when dim, I may have some overhead issues. Personally, I don't think always using a different variable name for every routine is necessarily a good technique (ie. dim strSQL as string, dim strSQL2 as string, dim strSQL3 as string, etc...etc...) or dim rs1 as adodb.recordset, dim rs2 as adodb.recordset, dim newrs3 as adodb.recordset, etc... - the point being, try to reuse variable names.) I've seen applications grow and grow in utilizing memory when using a different variable name for every routine. I had a developer do this once and overhead did become an issue (along with other issues.)

    Now maybe when it comes .NET, I'll have to rethink my always use of variants. But for vba and MSAccess apps, I've seen no issues (but maybe I've just been lucky in all the apps I've been creating over the years (even very large applications with extremely large recordsets.)
    Last edited by pkstormy; 12-21-08 at 16:02.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  8. #8
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    its down to perspective
    to me using a variant as the default datatype is sloppy and its bad practise, it can make errors difficult to diagnose.

    but thats not a personal criticism thats jsut how I see it when writing my code, so there is no need to be defensive, if we all did things the saem way the world would be very very dull or run by accountants (essentially the same thing)

    To a certain extent its a bit like the argument between the C approach (no safetys do everything yourself) and the BASIC approach lots of safeties you have to ry to screw things up. usually Im a clear believer that safety is better but on this one I'd want to know is functions are containing the wrong data or datatype.. as if the value is incorrect then that indicates to me that the design assumptions are wrong. in the .NET world I'd just overload the function to handle such issues where required.

    I haven't had significant data overflows or underflows since developing an application that brought trig functions to a variant of COBOL which had very limited mathmatcial support. IIRC I managed to get accuracy down to 5 or 8 decimal places
    I'd rather be riding on the Tiger 800 or the Norton

  9. #9
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    I try my best to avoid variants, but sometimes, it is just so convenient to use them every now and then.

    Interesting discussion on the performance thing
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  10. #10
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Missinglinq
    Disagreeing is your right, of course, but you're full of it!
    If there is one thing Izy is not full of, it is "it".
    This stuff is documented all over the place:
    http://www.example-code.com/vb/mid.asp
    No difference between a variant and a string? No cost to converting from one to another? Are you kidding?
    Quote Originally Posted by Missinglinq
    If it really made any difference, you'd see it used all the time, here and on the other half dozen forums I frequent.
    Blx. Common practice is common practice, not good practice.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  11. #11
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Not to get off the original subject of $ but regarding datatypes for variables. Regardless of the datatype, I've found it seems important to keep variable names consistent throughout an mdb. It seems to cause more overhead if you name a variable differently each time. I had a developer do this once (calling each recordset a new name: ie. Dim rsMyRoutineToDothis as adodb.recordset and then name his next routine Dim rsMyRoutineToDothat, and so on and so on as well as all his other variables.) This seemed to cause a lot of overhead.

    I personally use rs consistently throughout the mdb for recordsets.

    Anyone's thought on this?

    (and the only thing Izy is full of is lots of knowledge from real world experience. Misslinglinq also makes some good points.)
    Last edited by pkstormy; 12-22-08 at 20:39.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •