|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Inconsistent fso result.always found it OK up until now. I select a folder, and using code snip below test for the existence of files within the folder using two instr criteria, "zip" and an account number. This has worked fine during days of testing, but suddenly failed with a folder contains 3 files with .zip suffixes. In this case it only finds the first file. All other folders with varying numbers of zip suffixed files always return all files. I changed the criteria to be (dot) .zip which is what I meant to code in the first place, and it finds all 3 files. Why is an instr criteria of zip different from .zip? Code snip: For Each File In FilesObject If InStr(File.Name, "zip") And InStr(File.Name, "0011444") Then MsgBox File.Name End If Next Files in folder: BRS~0573~0011444000~WRETL~tswgtn3.zip BRS~0573~0011444000~WRETL~tswgtn3A.zip BRS~0573~0011444000~WRETL~tswgtn3B.zip Works fine with these files and 20 similar in same folder. (different account criteria) BRS~0100~0009432000~WPREM~643878.zip BRS~0100~0009432000~WPREM~643878A.zip BRS~0100~0009432000~WPREM~643878B.zip Works now but I hate these inconsistencies - any one have any ideas. For reliability, should I go back to DIR or create text file and use ODBCdriver with an SQL statement. TIA Ian B "Ian B" <ian(TakeO***@docspro.co.nz> wrote in message Actually it's lucky that you ran your code on some files that produced your news:%23rObdPFKGHA.3728@tk2msftngp13.phx.gbl... > Why is an instr criteria of zip different from .zip? > <snip> > If InStr(File.Name, "zip") And InStr(File.Name, "0011444") Then unexpected result before you let the code go, because it would have caused a lot of problems in the field. It's not the fso that is the problem, but rather the specific way you have performed the Instr test. Instr (as you almost certainly already know) produces a numeric result that tells you the position of the first character in the substring (if it is found) and zero if it is not found. So, in the above specific case the code is exactly the same as: If 36 and 10 Then . . . As you probably know, the And function is a standard bitwise operator and it looks at the bit pattern of the numbers, which in this specific case are: 100100 001010 The result of that "And" will of course contain a 1 only in the bit positions where the bits in "both" values are 1. In the above specific case there is no bit position which satisfies that condition, and so all of the bits in the result will be zero. In other words, 36 And 10 equals zero. So, the test you are doing will produce a zero result when the there are no "set" bits in the same position in both numbers, and a non zero result where there is at least one bit that is "set" in both numbers. Obviously that is not the test you wished to perform. To fix the problem you need to change your code to somehting like: If InStr(File.Name, "zip") <> 0 And InStr(File.Name, "0011444") <> 0 Then (Watch for line wrap on the above line). Have fun :-) Mike "Mike Williams" <M***@WhiskyAndCoke.com> wrote Or something like:> > To fix the problem you need to change your code to somehting like: > > If InStr(File.Name, "zip") <> 0 And InStr(File.Name, "0011444") <> 0 Then > If LCase$(Right$(File.Name, 3)) = "zip" Then If Instr(File.Name, "0011444") > 0 Then ' ... whatver ... End If End If HTH LFS Thanks Mike & Larry.
It is of course, my improper use of Instr which is at fault. However, I have got into a (bad) habit of using Instr as below. If InStr("Fred", "red") Then MsgBox "True" Else MsgBox False End If Without an "And/Or" factor this appears to reliably return the correct result. I have only used this abbreviated Instr in this latest project and have prudently replaced all instances with proper usage. Again thanks for your assistance. Ian B Show quoteHide quote "Ian B" <ian(TakeO***@docspro.co.nz> wrote in message news:#rObdPFKGHA.3728@tk2msftngp13.phx.gbl... > I see the fso scripting object occasionally getting "bad press" but have > always found it OK up until now. > I select a folder, and using code snip below test for the existence of files > within the folder using two instr criteria, "zip" and an account number. > This has worked fine during days of testing, but suddenly failed with a > folder contains 3 files with .zip suffixes. In this case it only finds the > first file. > All other folders with varying numbers of zip suffixed files always return > all files. > I changed the criteria to be (dot) .zip which is what I meant to code in the > first place, and it finds all 3 files. > > > Why is an instr criteria of zip different from .zip? > > Code snip: > For Each File In FilesObject > If InStr(File.Name, "zip") And InStr(File.Name, "0011444") Then > MsgBox File.Name > End If > Next > > Files in folder: > BRS~0573~0011444000~WRETL~tswgtn3.zip > BRS~0573~0011444000~WRETL~tswgtn3A.zip > BRS~0573~0011444000~WRETL~tswgtn3B.zip > > Works fine with these files and 20 similar in same folder. (different > account criteria) > BRS~0100~0009432000~WPREM~643878.zip > BRS~0100~0009432000~WPREM~643878A.zip > BRS~0100~0009432000~WPREM~643878B.zip > > Works now but I hate these inconsistencies - any one have any ideas. > For reliability, should I go back to DIR or create text file and use > ODBCdriver with an SQL statement. > TIA > > Ian B > > > > Break that habit. If you ever switch to VB.Net, the compiler will refuse to
comple your sample code. If you don't switch, it will lead to hard to diagnose bugs at runtime. Mike Ober. Show quoteHide quote "Ian B" <ian(TakeO***@docspro.co.nz> wrote in message news:eqsp3xSKGHA.3492@TK2MSFTNGP09.phx.gbl... > Thanks Mike & Larry. > > It is of course, my improper use of Instr which is at fault. > > However, I have got into a (bad) habit of using Instr as below. > > If InStr("Fred", "red") Then > MsgBox "True" > Else > MsgBox False > End If > > Without an "And/Or" factor this appears to reliably return the correct > result. > I have only used this abbreviated Instr in this latest project and have > prudently replaced all instances with proper usage. > > Again thanks for your assistance. > > Ian B > > > "Ian B" <ian(TakeO***@docspro.co.nz> wrote in message > news:#rObdPFKGHA.3728@tk2msftngp13.phx.gbl... > > I see the fso scripting object occasionally getting "bad press" but have > > always found it OK up until now. > > I select a folder, and using code snip below test for the existence of > files > > within the folder using two instr criteria, "zip" and an account number. > > This has worked fine during days of testing, but suddenly failed with a > > folder contains 3 files with .zip suffixes. In this case it only finds > the > > first file. > > All other folders with varying numbers of zip suffixed files always return > > all files. > > I changed the criteria to be (dot) .zip which is what I meant to code in > the > > first place, and it finds all 3 files. > > > > > > Why is an instr criteria of zip different from .zip? > > > > Code snip: > > For Each File In FilesObject > > If InStr(File.Name, "zip") And InStr(File.Name, "0011444") Then > > MsgBox File.Name > > End If > > Next > > > > Files in folder: > > BRS~0573~0011444000~WRETL~tswgtn3.zip > > BRS~0573~0011444000~WRETL~tswgtn3A.zip > > BRS~0573~0011444000~WRETL~tswgtn3B.zip > > > > Works fine with these files and 20 similar in same folder. (different > > account criteria) > > BRS~0100~0009432000~WPREM~643878.zip > > BRS~0100~0009432000~WPREM~643878A.zip > > BRS~0100~0009432000~WPREM~643878B.zip > > > > Works now but I hate these inconsistencies - any one have any ideas. > > For reliability, should I go back to DIR or create text file and use > > ODBCdriver with an SQL statement. > > TIA > > > > Ian B > > > > > > > > > > > 
Other interesting topics
|
|||||||||||||||||||||||
