realbasic-nug.fr
[Top] [All Lists]

Re: postgreSQL et Mac Intel

To: REALbasic NUG French <realbasic-nug dot fr at lists dot realsoftware dot com>
Subject: Re: postgreSQL et Mac Intel
From: Michel LO <michel dot lo at albireo dot biz>
Date: Wed, 28 May 2008 14:40:09 +0200
Authentication-results: mx.google.com; spf=pass (google.com: domain of realbasic-nug dot fr-bounces at lists dot realsoftware dot com designates 66.116.103.65 as permitted sender) smtp dot mail=realbasic-nug dot fr-bounces at lists dot realsoftware dot com
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug dot fr at lists dot realsoftware dot com
References: <240CEAE3-80F8-4565-A7E2-474A705BFEF2 at mac dot com> <0FD3A1BF-B3A8-4B76-9908-BF3447CB8673 at realsoftware dot fr> <962E46BD-1FFD-483C-B94A-644E76250CAF at mac dot com> <FF9EAC26-95FD-4698-BFA2-76ED923E115A at realsoftware dot fr> <E06AF1F0-D067-4931-B67C-779AB662FF29 at mac dot com> <5F6DA951-062C-4EF8-81CD-4117CC5E6159 at gmail dot com> <6D026DA6-522E-4BB3-99D1-4164D0AC11F8 at mac dot com> <4C43911F-B375-4378-A647-4D151BD3B7DA at gmail dot com> <2936BE66-901A-4C12-814E-C6BDA69F3742 at mac dot com> <B70B62A7-5A21-4DA7-9345-835E0C090A85 at gmail dot com>
Et pour en rajouter dans le sens de Eric Ferrer, et contrairement à ce que dit Robin de kat, cela peut avoir un grosse influence de fermer et réouvrir la base à chaque fois.

En effet, ouvrir une base pour créer un handle nécessite impérativement un accès disque. Un seul accès, ce n'est pas trop grave, mais en enfiler plusieurs les uns derrière les autres cela peut compter fortement.

Il y en a déjà de toute façon pour lire/écrire, mais fermer et ouvrir en rajoutent ...

Une expérience simple pour le toucher du doigt : faire une boucle de 100 itérations (pour bien s'en rendre compte) dans laquelle l'ouverture et la fermeture ne sont pas dans la boucle, et refaire la même dans laquelle ils sont dans la boucle.

Pour ce qui concerne les modules, j'ai pris l'habitude de faire un module global "commun" dans laquelle je crée les variables avec un scope global et dans lequel je crée les méthodes comme l'indique Eric. Et même, en plus, je crée les constantes dans le même module "commun", ce qui me permet de mieux gérer les textes pour reprendre les mêmes et ne pas les mettre deux fois (par exemple, reponse_oui , reponse_non , CR_LF , etc...), ce qui est mieux quand on gère ensuite le multilingue.


Michel Lo
BELT
45, rue Aristide Briand
92300 LEVALLOIS-PERRET

L'intégrité de ce message n'étant pas assurée sur internet, BELT ne peut être tenue responsable de son contenu. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur.

The integrity of this message cannot be guaranteed on the Internet. BELT can not therefore be considered responsible for the contents. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.



Le 28 mai 08 à 14:10, Eric Ferrer a écrit :


Le 28 mai 2008 à 08:38, Robin de Kat a écrit :

Toutes mes excuses

OK OK OK, acceptées, on va pas se fâcher.
Ceci dit, fais attention à ta manière de rédiger tes messages, je crois bien que ce n'est pas la première fois que tu "agaces"...
;-)

Si je me suis permis ce commentaire "hors sujet", c'est parce qu'il me semble que tu débutes sur RB.
Déjà gros indice : tu ne connais pas les modules...

Je ne me suis pas permis de faire un commentaire juste pour me "satisfaire intellectuellement" (j'ai d'autres domaines pour ça !).

J'insiste...
Je pense qu'il vaut beaucoup mieux rester connecté à une base de données tant que l'application est lancée. Depuis que je travaille avec des serveurs de base de données, je n'ai jamais vu une connexion se perdre sans une bonne raison (serveur planté, réseau HS...) Et de toute façon, si la connexion est perdue, tu le sauras en envoyant ta requête SQL : ton RecordSet ne contiendra aucun enregisrement (ou sera nil) et les propriétés .Error, .ErrorCode et .ErrorMessage de ta base de données devrait t'indiquer de quelle erreur il s'agit.

Evidemment, si ton appli n'a besoin que très occasionnellement des données de la base, il vaut effectivement mieux s'y connecter uniquement quand c'est nécessaire (et puis ça évite les "time out").

Par contre, plutôt que de répéter les mêmes lignes de code de connexion à la base, utilise une méthode globale (= dans un module, nous y arrivons) !
Plusieurs avantages :
        économie de temps durant le développement
        code plus léger
        plus facile à entretenir
        plus facile à faire évoluer

Ajoute un module à ton projet et dans ce module, crée une méthode "ConnectToDB" (par exemple). Cette méthode retourne une "PostgreSQLDatabase" si la connexion a été établie, nil dans le cas contraire.

Ainsi tu peux remplacer ces lignes :

        Dim db as PostgreSQLDatabase
        db= New PostgreSQLDatabase
        [...]

        db.host="localhost"
        db.port=5432
        db.DatabaseName="sxcollecte"
        db.Username="postgres"
        db.Password=""

        If db.connect then

par :


        Dim db as PostgreSQLDatabase
        [...]

        db = ConnectToDB()

        if db <> nil then



Si l'adresse du serveur, son port, le nom de la base de données ou les paramètres d'identification changent, tu n'as qu'à les modifier en un seul endroit.

Et si finalement tu optes pour une connexion permanente à ta base de données, le module peut aussi contenir tout ce qu'il faut pour gérer cette connexion.

Les modules, c'est simple, pratique et puissant. En les nommant correctement, en utilisant les "scopes" "global", "public" et "private", tu obtiens un code plus rationnel, plus lisible, plus facile à débuguer.

Bonne continuation
Eric




<Prev in Thread] Current Thread [Next in Thread>