how can i find out if the contents of a variant datatype is a string 1

[Juddy58]

Hi, just a quick one. I have a global variant variable in my database, it can contain any type of data. Does anybody know of a function like "isnumeric" but will tell me if the value in it is a string?
I have done a few searches and haven't found what im after.
Thanks
Justin

 

[missinglinq]

There's no string counterpart to IsNumeric, if that's what's you're asking. But why not use the inverse, i.e.

If Not IsNumeric(YourData) Then

this will tell you if there are non-numeric characters in the data, which would be, by definition, a string.

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[danvlas]

Could be useful to check IsDate too.

HTH


Daniel Vlas
Systems Consultant

http://www.geocities.com/danvlas/AutoMail.html

 

[TheAceMan1]

. . . and how about:

[blue]Debug.Print TypeName([blue][b][i]variablename[/i][/b][/blue])[/blue]

See Ya! . . . . . .

 

[Juddy58]

Thanks for the reply, Thats what I thought of doing, the problem I have is if you have a variant datatype that is stored as a string but it just contains a number eg, "2" and you run the isnumeric function you get a result of true when it really is stored in the variable as a string so it should be false (sorry about my wording it is hard to explain.), my current attempt at a solution is to look for quotes " in the variable but im not having much luck so far!
Thanks
Justin

 

[danvlas]

Then TypeName is the solution, as pointed out by TheAceman1...


Daniel Vlas
Systems Consultant

http://www.geocities.com/danvlas/AutoMail.html

 

[Juddy58]

sorry ace man you must have written your response while i was writing mine. Can I say one thing you are definetily the ACE MAN that is exactly what i need thanks!!! and a star!
Justin

 

[JoeAtWork]

it just contains a number eg, "2" and you run the isnumeric function you get a result of true when it really is stored in the variable as a string so it should be false

Ummm, no, the whole purpose of the IsNumeric function is to check if a non-numeric type (such as a string) could be converted to a number.

Personally, I shun the Variant data-type. Because it can accept any type of value, it makes it so much easier to introduce logic errors in your code. And as you have found out, you can't predict what the variable will be interpreted as.

 

[missinglinq]

TheAceMan1, won't

Debug.Print TypeName(variablename)

always return Type Variant, if the variable is declared as a Variant, regardless of the type of the data that's fed into the global variable?

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[TheAceMan1]

Howdy missinglinq . . .

In A2K:

[blue]Option Compare Database
Option Explicit

Public varDat

Public Function qqq()
   Dim x As Byte
   
   Debug.Print TypeName(varDat) 'Empty
   x = 45
   varDat = x
   Debug.Print TypeName(varDat) 'Byte
   varDat = "12345"
   Debug.Print TypeName(varDat) 'String
   varDat = 12345
   Debug.Print TypeName(varDat) 'Integer
   varDat = #12/27/1949#
   Debug.Print TypeName(varDat) 'varDate

End Function

'Produces the following output in the immediate window:

?qqq
Empty
Byte
String
Integer
Date[/blue]

Hope this isn't a version issue! . . .

See Ya! . . . . . .

 

[missinglinq]

So, the answer to my question:

won't Debug.Print TypeName(variablename) always return Type Variant, if the variable is declared as a Variant, regardless of the type of the data that's fed into the global variable?

would be "No!"


I'd have taken your word for it! You are, after all, The(Ace)Man(1)!

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[TheAceMan1]

missinglinq . . .

The post was actually for [blue]JoeAtWork[/blue] who said:

[blue]Personally, I shun the Variant data-type. Because it can accept any type of value, it makes it so much easier to introduce logic errors in your code. [purple]And as you have found out, you can't predict what the variable will be interpreted as.[/purple][/blue]

Just another case of selecting the wrong name!

See Ya! . . . . . .

 

[JoeAtWork]

I said you couldn't predict what type the VBA runtime would decide the variable should be when it is assigned a value. This is perfectly true. For example, given you have a textbox on the form and assign it's value to a variant variable:

Dim varAnything As Variant

varAnything = txtMyTextBox.Text

Now, what type is in that varaible? The answer: it could be an a long, a string, a date, etc. In fact, it is whatever type VBA has decided it probably should be. And hence, almost every time you want to do something with that variable you need to check what type it is to find out if what you are doing with it is valid. Which is exactly the situation of the OP.

If you know that a "2" in the textbox should be a string, why not assign it to a string variable? That eliminates the need to check what type it is.

There is almost never a good reason for using a Variant. They easily lead to errors, often the very subtle and hard to duplicate kind. Use strongly typed variables instead. For the same reason that most professional programmers will tell you to always use Option Explicit.

 

[TheAceMan1]

My God JoeAtWork . . .

The point is [blue]TypeName([purple]variablename[/purple])[/blue] alleviates the problem! . . . [blue]its so easy to find out![/blue]

See Ya! . . . . . .

 

[TheAceMan1]

JoeAtWork . . . hit submitt too soon! . . .

Oh and I forgot! . . .

[blue]There is almost never a good reason for using a Variant.[/blue]

I can prove to you in court . . . variants have a powerful play in our programming! . . . a step up for you once your eyes are open! . . .

See Ya! . . . . . .

 

[JoeAtWork]

The point is TypeName(variablename) alleviates the problem! . . . its so easy to find out!

The problem never appears if you use strongly typed variables. Variants require more overhead, more lines of code, and introduces ambiguity in your code.

variants have a powerful play in our programming! . . .

Variants are powerful, that's why they should be used with discretion. They should only be used when other options will not accomplish the task. It's a choice that should be justified every time it is made.