Developing Environments

[ASherbuck]

Has anyone noticed any problems building there access packages in Vista and then deploying them on Windows XP?

For the last 3 months I haven't had any problems until recently. I've tracked the issue down to a parsing issue. I have a bit of code that parses data it's set up akin to:

If InStr(String, "delimeter") Then
     yada yada
     else
     yabidi yabidi
End If

On vista it runs fine, when I get it into windows XP it doesn't. I have 3 XP machines that are identical and all have the most recent updates, on 2 or the 3 it goes the ELSE yabidi yabidi and on the other XP and vista machines it gives Yada Yada and this is for the exact same data. I can't figure out why I have such a strange anomaly, I've uninstalled, whiped all traces of Access and Office, Reinstalled, tried developing on the XP Machines but it still won't parse.

I'm confuzzled, any advice?

 

[KenHigg]

Wonder what would happen if you did something like:

msgbox InStr(String, "delimeter")


or

If InStr(String, "delimeter") = true Then
yada yada
else
yabidi yabidi
End If

???

 

[MSAccessRookie]

If InStr(String, "delimeter") Then
     yada yada
     else
     yabidi yabidi
End If

It looks as if your code is assuming that the function InStr returns True/False. It is my understanding that it returned the following:

1. A number less than the length of the string if the taget was present.
2. Zero (0) of the string was not found.

I was unaware that a True/False comparison could be made, and what the effect of doing so would be. Perhaps there is a difference in the way that Access handles this condition under Vista as compared to XP.


Update: I see that Ken also indicated that True/False was an option. As I said I was unaware of the possibility. Helping me to get a more detailed understanding would be appreciated.

 

[doco]

I was unaware that a True/False comparison could be made

Any non zero integer == TRUE and zero == FALSE

 

[ASherbuck]

You're right and should have included this but I overlooked it. Through my testing I have set it to

If Instr(string, "delimiter") > 0 Then

But I haven't had different results.


Any message boxing, I tried that as well. Right before the parse I msgbox myself the string, "Gigantuam text box" fills the screen and then after parse I msgbox the result and I get the else statement. Which is basically "String Not Parsable".


The String basically has a section where it says "1. " *new line*. So my delimeter is "1. " & vbcrlf. It miffs me off when I'm sitting looking right at it and see machine 1 grab it and 2 and 3 miss it.

 

[MSAccessRookie]

Any non zero integer == TRUE and zero == FALSE

Until it is not. When we migrated to SQL server, we had a problem between "TRUE=1" and "TRUE=-1" between the two platforms, that caused applications no end of grief. "FALSE=0" on both platforms, so we had to make sure that EVERY Comparison was in the form (If False Then Yakkity Else Yada) instead of the form (If True Then Yada Else Yakkity)

At the same time, all numeric based tests were changed to numeric results to eliminate any future problems.

That is why I was asking.

 

[Banana]

To be a bit pedantic,

False=0
True=Not False.

That is different from saying True is any non zero integer and False being zero even though they appear to be a converse. If you search for VBA boolean thread I started, Brent posted examples of what kind of weirdness you can see when you do various comparisons.

 

[georgedwilkinson]

On vista it runs fine, when I get it into windows XP it doesn't. I have 3 XP machines that are identical and all have the most recent updates, on 2 or the 3 it goes the ELSE yabidi yabidi and on the other XP and vista machines it gives Yada Yada and this is for the exact same data. I can't figure out why I have such a strange anomaly, I've uninstalled, whiped all traces of Access and Office, Reinstalled, tried developing on the XP Machines but it still won't parse.

Other's advice will help solve the problem. I'm just curious...do the computers have different chip sets? If so, what?

I can't imagine XP behaving 2 different ways just based on the computer it's running on.

Unfortunately, I take a lot of shortcuts like the one your code took (i.e. setting boolean fields to calculations that return something other than boolean).

 

[ASherbuck]

This is great, it's definitely steered me in the proper direction.

Here is what I've got it down to.

I opened my accdb on my normal machine and on one of the XP machines that it isn't working on. I tossed in the MsgBox InStr(string, "delimiter") On the working box it give me 3447, so bingo thats why that one works. On the nonworking I get 0. Nice . . .

This data is an innertext from a website, I navigate through an ActiveX control on the Form. I compared the innertexts of both boxes. On the working boxes I get my delimiter "1. " & vbcrlf. On the non working boxes I get 1. Title.

Interesting that the same program, using the same code, same network, same activex control can have issues with the innertext.

So, I have to change my delimeter, luckily I already see a quick change that will more than likely work for both.

Thanks for all the help I got from you guys, Id used msgbox to debug before but I never knew I could use it in this way. I'm definitely clicking some scales.

 

[georgedwilkinson]

You might want to try

Debug.Print

instead of msgbox for some of your troubleshooting. Makes it easier to cut and paste the result.

Did you get a chance to look at the CPUs on the working/non-working boxes?

 

[ASherbuck]

I can get a look at them for you, but it will have to be either later tonight after everyone has left or early tomorrow morning.

 

[georgedwilkinson]

No big deal...just a curiosity for me really. I'd kinda like to understand why you had the problem.

 

[KenHigg]

I was wondering if the same erorr happens with other functions that return true/false?

 

[boblarson]

Also when one function works on one computer but not on another (especially with different operating systems, but not exclusive to that) you can suffer from MISSING REFERENCE issues and have to deal with that.

 

[georgedwilkinson]

Surely Instr() is built right into Access though?

 

[boblarson]

Surely Instr() is built right into Access though?

Yes, but you can still have DAO reference problems of which this is involved. Many times it is solved just by unchecking the DAO reference and then adding it back if it doesn't do it automatically. Remember, different computers can have different MDAC levels so you can still run into those problems regardless.

 

[doco]

Works for me...

Private Sub test_func()
    Const DELIM As String = "_"
 
'   put any integer in the argument list
'   zero always returns false
'   any non zero integer always returns true
'   tested with and without the DELIM in string
 
    If dcReturn(InStr("TEST_THIS", DELIM)) Then
        MsgBox "Return"
    Else
        MsgBox "No Return"
    End If
End Sub
 
Public Function dcReturn(ByVal iInteger As Integer) As Boolean
 
    dcReturn = iInteger
 
End Function

And this way as well

Private Sub test_func()
    Const DELIM As String = "_"
    
'   put any integer in the argument list
'   zero always returns false
'   any non zero integer always returns true
    If InStr("TEST_THIS", DELIM) Then
        MsgBox "Return"
    Else
        MsgBox "No Return"
    End If
End Sub

 

[ASherbuck]

George: They're both Core 2 Duo's for Cpu.

I don't think this is an issue with INSTR()

I'm getting two different sets of text when I use Document.Body.Innertext on the same website on two different machines through the same ActiveX web browser control on my form. It's replicated everytime I've tested. It's odd to me that it would pull a different set of data each time.