Search results

The reason that ... ?a=(3 and 8) True Occurrs is because (a) becomes a Variant, and Variants are initialized to Empty, and Empty is interpretted as 0 in a numeric context and a ZLS in a text context, so writting ... ? a=(3 and 8) is the same as writting ... ? 0 = (3 and 8) Which...

>> After testing some more I have found that (3 and 1) even though returning the "bitmask" in the immediate window, converts into boolean when assigned directly to a variant. Yourvariant = (3 and 1) stores True not 1 << .. Umm ... and how did you test that? ... Give this a shot: Public...

Hello Banana ... >> ... but rather "BitMask And SomeOption" << I hate to get nit-picky but the term "BitMask" is the filter you are masking a value with. In other words we mask the bits we are not interested in with a 0 in the respective bit position. So in the above, the bitmask is...

Hello dcb ... >> Access sees Cint(True) as -1 But a Boolean remains a bool no matter what.. Thus Cbyte(CBool(Cint(True))) = 255 << I am not sure of the point you are trying to make. Coverting a boolean of True, which is supposedly returns a value of -1, *should* cause the CByte() function...

>> So not everything that is true is equal to True << Yep ... here is one of my favorite sequences of examples ... ? True = -1 True ? CByte(True) 255 ? CByte(-1) <overflow error raised!! --- but I thought True equals -1?>

And on the flip side ... :) .. I use, and encourage others to use, the "(15 and 8)=8" for safety, readabiliy, AND more options. Readability: If we use "15 and 8" most of us don't immediately know which one is the bit mask and which one is the value being masked, and with variable names and...

However ... -1073741824 And -2147483648 Results in a negative ... so ... probably best to test for the specific value of the mask or <>0 ... (-1073741824 And -2147483648 <> 0) Or ... (-1073741824 And -2147483648 = -2147483648) Also, since we are dealing with VBA's AND and the code...

>> As long as the SearchForm is opened first and a LotNumber is entered, it should show only results that meet that criteria, yes? << Yep! ... :)

Definately a good point Dave, and if that is a concern, the Format() pattern I suggested could just be set to: "00/00/00" Then the CDate() will use the settings on the PC to determin the 19 or 20 in this century, and 20 or 21 in the next, thus removing the hard coded century.

Where do you want the result to be? ... or how do you plan to use the expression/solution? In a query or control source of a text box on a form: CDate(Format(Mid([FieldName],InStr([FieldName],"E") + 1, 6),"00/00/\2\000")) Or... you could create a VBA User Defined Function: Public...

Be sure to read the edits to my previous post, I added a couple more options ... :)

Option 1: If your combo is on the form you wish to reference, then create and name a control that is bound to the field you wish to be the filtering value, then you can simply reference that control in your SQL statement. Control Name: txtMyFilteringField Control Source: FieldName Combo's...

>> Is there any easy way to find out the corrupted records using query? << Not really with a query. What I do to find/eliminate the problem is do a FIELD by FIELD copy/append FROM the suspected corrupt table to a NEWLY CREATED table with and IDENTICLE structure .. make sure the destination...

>> If your nitpicking, pick right... it is 30-dec-1899, not jan << ROFL!!! ... I can't beleive I actually wrote Jan! <shaking my head shamelessly .... I should have just went to bed! :eek:> ... Thank you for correcting the information, {I will edit the post to indicate error!} >> the big...

>> A date is 'not really a date' it is a number of days that have passed since 01-jan-1900. << In MSAcess the base date is 30-jan-1899 00:00:00 {edit --- CORRECTION: MSAccess date base is 30 dec 1899} >> There simply is no (that I know of) date only thing. << mailman has already said it...

You're welcome ... but ... your reply does not seem to make sense? DoCmd.SetWarnings False Will not suppress the errors generated by CurrentDb.Execute. The code and SQL I provided is correctly syntaxed and the SQL you posted originally is incorrectly syntaxed (even if you add the space) ...

Hello Genesis ... I have shown you in your previous similar threads as to a proper syntax you need ... Specifically here: http://www.access-programmers.co.uk/forums/showthread.php?p=902813#post902813 ... and the fact that Access 2007 has a bug with reformatting the proper SQL statement...

>> But then the password is embedded in your VBA code. This is only a mild improvement. Sure, the MDE strips out the VBA code and leaves only the p-code, but strings like a password are still there. << I definately do not dis-agree.

>> What good is a password that has to be embeded in your table links or provided to all the users? << That is incorrect, you do not need the pwd embedded in the table link to access a pwd protected db through a linked table. You can create a connection to the back end programmatically and...

Regardless of your opinion (or mine for that matter) about the new features of the Access 2007 format, if the person/customer is required/requested to utilize them, they will lose ULS and Replication. ULS, which is easily cracked anyway, is not a huge loss (my opinion of course), as it gives...