>>>>Hi,
>>>>
>>>>This is a follow up my thread on the same subject. Just to refresh:
>>>>I store (un-encrypted) a string that consists of "Y" and "N" in a 250 char field GRP_ACCESS (in SQL Server). Each position corresponds to a feature in the application. When a user logs in, based on his credentials, he may or may not have access to a feature (based on the value in the GRP_ACCESS field).
>>>>
>>>>I tried to encrypt the values in this field using the function cipher() (created by S. Berezniker). This function creates an encrypted string (based on the "YYYYNNNNYN..." But if one were to look at the encrypted field you can clearly see a pattern. For example, the users who have/had all "Y"s in the un-encrypted field get the same encrypted string. It is just the encrypted string has many non-ascii characters; so it looks unreadable. But if someone wants to, they can simply store the field value into a variable and then execute the UPDATE table and set this value in all records. I doubt my customer would do it. But, I would like to explore other ways to encrypt the field.
>>>>
>>>>If you have any suggestions, please let me know.
>>>
>>>Use integer field instead.
>>>http://www.atoutfox.org/articles.asp?ACTION=FCONSULTER&ID=0000000348
>>
>>The URL brings to the empty page. It is not a dead link but I see no description/content.
>
>It's weird, you get to download a .mht file, which is the packed webpage or email, i.e. self-contained html. I've managed to extract just text, using TotalCommander's Lister:
>
>

atoutfox.org
>ATOUTFOX - 2006
>La double personnalité d'un integer.
>
>Cet article m'est venu à l'idée lorsque je discutais avec un collègue sur l'utilité d'un integer dans une application = et je me suis aperçu que mon collègue ne connaissait pas la deuxième personnalité d'un integer. Pour lui un integer était un type de champs style numérique qui pouvait qui prend= re seulement 10 chiffres (donc pour lui limité en soit) et la valeur maximale qu'un champs integer pouvait prendre était 2147483647 et la valeur minimale est de -2147483647 (donc encore un fois pour lui limité). A titre de compa= raison un champ numérique (sans décimale) peut avoir 15 chiffres (à t= itre de précision) donc les valeurs sont de - .9999999999E+19 à .9999999999E+2= 0, qui pour lui représentait un avantage définitif. Un des désavantages d'un champ numéri= que est qu'il est de 8 bytes et un integer est de 4 bytes.
>
>Mais, je lui ai fait remarqué la double personnalité d'un champ integer qui pour les besoin de la cause serait très utile. Nous cherchions un moyen pour attribuer un (ou des ) statut(s) différent(s) pour un commande d= ans un application (ie. Commande retenue pour au niveau du crédit, commande retenue pour un manque de stock, commande crée et non imprimé, commande crée et imprimé, commande livrée etc.) La solution qu'il proposait était d'utiliser des champs logiques pour chaque statut, Je lui ai fait remarqué qu'il en faudrait une quinzaine (En plus des autres champs pour total, taxes etc). Ma proposition était un= champ integer. Il ne voyait pas comment déterminer le statut d'une commande en évaluant le contenu d'un champ integer.=
>
>C'= ;est a ce point que je lui ai expliqué la double personnalité d-= 7;un champs integer (possiblement la vrai personnalité). Oui un champ int= eger peut contenir une valeur numérique, mais un champ integer est aussi composé de 32 champs logiques (booléen) qui peuvent être utilisé avec un seul champ. Donc pour chaque bit (terme qui identifie chaque champ logique contenu dans un champ integer, peut être r&eacut= e;glé à vrai ou faux (.t. ou .f.) (Ou 0 et 1) .= Mon collègue commençait à voir l'utilité d'un champ integer. Voici quelques exemples d'un champ integer.
>CLEAR
>
>CREATE CURSOR moncurseur= (champflag i)
>
>INSERT INTO moncurseur (champflag) VALUES (0x00000001) && ou 1
>
>FOR i = 0 TO 31
>
> ? BITTEST(champflag,i)
>
>ENDFOR
>
>=
>
> Le code ci haut nous donne une série de 32 valeurs (32 bits) logiques. A noter que la premiere valeur est .T. et les 31 autres sont .F= ., Donc on a utilisé la bit 0 pour indiqué un statut pour notre commande. Il nous en reste 31 autres que l'on peut utiliser, pour indiquer le statut de notre commande, et l'avantage de cette technique est que si on mets la bit 1 (deuxieme bit dans la série) a .T. la premiere bit reste a .t. aussi, donc on peut accumuler le statut de la commande sans pe= rdre les statuts déja acquis.
>CLEAR
>
>CREATE CURSOR moncurseur= (champflag i)
>
>INSERT INTO moncurseur (champflag) VALUES (BITSET(champflag,0)) && ou 1
>
>FOR i = 0 TO 31
>
> ? BITTEST(champflag,i)
>
>= ENDFOR
>
>
>
>L= e code ci haut va mettre le bit 0 (premier bit) a .t. (ou 1). Si par exemple plutard dans la validation de notre commande, elle ob= tient un statut qui nous indique que l'on devrait mettre le bit 1 (deuxieme bit) a .T., n'a qu= 'a faire ceci
>x= BITSET(champflag= ,1)
>
>REPLACE champflag WITH x
>
>FOR i = 0 TO 31
>
> ? BITTEST(champflag,i)
>
>ENDFOR
>
>E= t on remarque que le deux bits (0 et1 ) sont a= .T..
>
>S= i pour une raison donnée nous devrions changer un bit de .T. a .F. on a = qu'a spécifier le bit et utiliser BITCLEAR
>x= BITCLEAR(ch= ampflag,1)
>
>REPLACE champflag WITH x=
>
>C= eci va remettre le bit 1 a .F. et maintenir le statut des autres bit tel quel.
>
>
>F= oxpro nous offre quelques autres fonctions a utiliser sur le bits. Comme BITAND= (),BITOR() etc. Consulter l-= 7;aide en ligne pour les autres fonctions.
>
>
>En conclusion, peut-etre cet article est inutile et tous le programmeurs FoxPro connaissaient le double utilité d'un champs integer et = que mon collegue était le seul, ou peut-etre qu'il y = en d'autre qui vont trouver ce champ plus utile a l'avenir.

>
>There are some remainders of MIME encoding but... here's a chance to practice your French (all of them).

Yes, right before you sent me the message, I realized that the there is a .mht file. And I can open in in the browser.
You are also right that this will be a good practice of learning French :)
Thank you and thank you, Mike.