L'intérêt d'un code dé-compilable est au contraire sa sécurité (cf linux dont les sources sont disponible qui ont moins de faille que les système à sources privées).
N'importe qui peut vérifier l'implémentation s'il a un doute.


Perssonellement j'ai utilisé DJDecompiler qui était très bien mais qui est devenu payant.

JAD en plugin eclupse et depuis 6 mois environs celui-ci
http://java.decompiler.free.fr

C'est un français qui l'a écrit, il requière le framework .Net et est disponible en standalone ou en plugin éclipse.

Je vous invite à l'essayer, l'interface graphique permet de naviguer très facilement dans une jar, war ou autre.

Si tu veux rendre ton code plus difficile à lire il existe des outils d'offuscation.
Tu peux aussi modifier le ClassLoader pour chiffre tes classes mais en analyse le ClassLoader qui ne peut être chiffer ont arrive toujours à voir le code; c'est juste plus long.

Voici les commentaires qui j'espère te permettrons d'évoluer.

Gestion des Exceptions : ici si un mauvais paramètre est donné à ton constructeur , que fera ta classe ?
#  catch (ParseException e) {
# e.printStackTrace();
# }


ta classe est utilitaires technique (nom de package ok. la norme sun voudrais [ton domaine].[ton projet].technique )
Ta classe devrait plutot devenir un Helper (ie classe abstraite avec toutes les méthodes static)

Pourquoi ne pas utiliser ResourceBundle dont c'est le rôle et qui gère la Locale en plus ?

Préférer le chemin du properties avec un accès au classLoader (valable pour un properties embarqué avec l'application)
Thread.currentThread().getContextClassLoader().getResource("fichier.properties")

Ton code est didactique mais est peu Objet.
Pourquoi ne pas utiliser java.util.Date et java.util.Calendar ?


Calendar cal = Calendar.getInstance();
cal.setLenient(false);
try {
cal.set(annee, mois, jour, 0, 0, 0);
cal.setTimeInMillis(0);

cal.add(Calendar.DATE, 1);

Date demain = cal.getTime();
} catch (Exception e) {
System.out.println("c'est pas une date");
}

Le principe de hashage des mots de passe est bon. l'utilisation de MD5 l'est un peu moins car des collisions ont été démontrées récement.
Il serait préféable d'utiliser SHA-1 qui est aujourd'hui plus sûr.

Sinon, source bien commentée et abordable par tous.

Il est vrai que l'utilisation des composants ADODB sont soumis à l'environnement du serveur, mise à jour de patch de sécurité, montée de version du MDAC ...

Le choix de ce composant a été motivé par la facilité d'implémentation.

Pour ce qui est du téléchargement en lui même, il faut surtout regarder au niveau des headers HTTP, en utilisant les même en J2EE , PHP ou autre, ils seront toujours valable.

pour ce qui est du blocage à 99%, je pense qu'il faut analyser les composants du serveur pour trouver ce qui cloche, ce code fonctionne depuis 3 ans sur un site privé qui a 400 utilisateurs.

juste un commentaire sur le count(*) et l'optimisation

il est à éviter car le moteur sql ramène les lignes avant de les compter.
il est plus judicieux d'utiliser Count (0) As NbLignes

WebForm1.aspx.cs manquant!

ici nous avons un gros proble quand à la validité de la date
ex: un 30 février de dérange pas du tout ni un 31 avril.....

aucun test n'est fais si ne n'est sur les caractères.
si tu veux voir un test qui prend en compte les années bisextiles et séculaires.
tu peux le trouver dans ma librairie javascript dispo ici