Il me semble que gérer 2 connexions simultanées sous Windev soit impossible. Je vais quand même m'en assurer.

Exact. Cela va même un peu plus loin : Il y a plusieurs fichiers (même nom, extension différente). Je contrôle d'abord si des métadonnées contenue dans le titre du fichier existent dans d'autres tables (T1, T2 et T3 par exemple) de ma base. Si oui, je les verrouille (BEGIN; SELECT FOR UPDATE ... pour chaque table) pour ne pas risquer qu'un autre utilisateur efface les données entre le contrôle et l'insertion (+LOG en fin de verrouillage). Puis j'insère les infos de ce fichier dans une table (T4) en récupérant l'ID de la ligne ajoutée (+LOG) + quelques clés étrangères (T1, T2 et T3). Je fais la copie des fichiers sur un emplacement réseau en les renommant avec le n° ID de T4. Si le transfert s'est bien passé, je COMMIT, je LOG que l'opération a été un franc succès et enfin j'efface les fichiers dans le répertoire d'import (si problème à ce moment, pas trop grave puisque les fichiers sont au bon emplacement et la base est à jour). S'il y a eu des problèmes, tout va dépendre de où cela s'est produit :

- Si c'est au moment de la recherche des meta données sur T1, T2 ou T3, il me faut faire un LOG puis ROLLBACK;. Il est nécessaire que j'ai l'info de la table en DF, mais au pire, si je perds le LOG de la première opération c'est pas trop grave (le message de log de l'erreur me permettra de retrouver facilement la source du problème).

- Si c'est au moment de l'INSERT, là encore, je peux faire ROLLBACK puis faire mon LOG. Je perds cependant 2 LOGs "process", là encore je peux m'en passer.

- Si c'est lors de la copie des fichiers, j'ai déjà réalisé un LOG indiquant la création dans la table de l'enregistrement. De plus, je LOG le transfert des fichiers 1 par 1. Comme ça, je peux savoir si c'est un fichier spécifique qui pose problème. Du coup, Si je fais un ROLLBACK, je perds ces LOG. Si je fais un COMMIT, je valide ma transaction alors que les fichiers ne sont pas déplacés.

Et c'est au niveau de cette opération que cela pose soucis. Ce n'est qu'un extrait de mon application, j'ai d'autres endroits avec les opérations multiples sur tables que je dois tracer (pour que le LOG serve à quelque chose en cas de défaut), mais qu'il ne faut pas que je conserve s'il y a eu un problème (les modif de tables hein, pas le LOG )

Donc, faire la gestion de l'erreur côté client risque d'être difficile puisque assujetti à la possibilité de connexion multiples simultanées.
Maintenant, si je veux faire du LOG côté serveur (et là encore si j'ai bien compris), il faut que j'utilise des clause exception, donc que je dialogue avec mon serveur soit avec des fonctions anonymes, soit que je crée une fois pour toute des fonctions sur mon serveur qui gère ces exceptions. C'est bien cela ?

Bonjour,

Désolé de cette absence de réponse, appelé sur des projets plus urgents...
Merci de votre aide.
Si je comprends bien, je n'ai pas le choix : il faut que je mémorise tous les évènements pour les inscrire à la fin de la transaction, car sinon ils seront effacés par le ROLLBAK (le cas échéant).
Dommage, j'espérais bien pouvoir faire une exception sur une table.

Mais je voudrais creuser un peu.
D'après vos commentaires, si je crée les fonctions qui vont bien sur le serveur, je devrait pouvoir intégrer une clause EXCEPTION qui me permettrait, en cas d'erreur, de remplir ma table LOG même en cas de ROLLBACK ?
Actuellement, une grosse partie de mes transactions se font en requête préparée. J'imagine que cela n'est pas la même chose.

Requête préparée = PREPARE blablabla;
Fonction = DECLARE etc ...

Cela me fait quelques modifs majeur de mon application...
Otez-moi d'un doute : les requêtes préparées sont valides uniquement le temps de la connexion qui les crée (actuellement, c'est comme ça que je fonctionne : à chaque connexion, je crée les fonctions préparées de l'utilisateur. Si x utilisateurs se connectent, j'aurai x requêtes préparées, chacune isolées des autre. Dès qu'une connexion disparait, ses requêtes préparées sont effacées).
Quid des fonctions ? Je les crées une fois pour toute sur mon serveur ?

Cdt

Bonjour,

Merci pour l'info. Je suis en train de tester dblink_exec sans connexion permanente (paramètres de connexion directement dans la commande) et pour l'instant, j'ai réussi à écrire dans ma table.
Il a fallu trouver le bon formalisme (notamment en ce qui concerne le doublage des ' ) mais j'y suis arrivé.

Reste à tester au milieu d'une transaction et je détaillerai la méthode pour les autres personnes qui se poseraient la même question que moi.

Cdt,

Bonjour,

C'est à ce moment que je réalise l'immensité de l'abime de ma méconnaissance de PostgreSQL

Merci beaucoup. Je prends 2 aspirines et j'essaye de comprendre comme ça marche
Pour l'instant, j'ai décomposé ma requête en 2 (de plus, cela me permet de récupérer l'ID pour un autre traitement ...), mais pour ma culture, je regarderai quand même votre syntaxe.

Merci encore.

Je suis en train de me demander si je ne cherche pas la complexité là où il n'y en a pas...

En gros, j'ai créé une table pour test avec 2 colonne bigint, puis j'ai créé cette fonction:

CREATE OR REPLACE FUNCTION insertion(
	idcol bigint,
	tableau bigint[])
    RETURNS void
    LANGUAGE 'plpgsql'
    AS $$
        BEGIN
	FOR i IN 1..array_upper(tableau,1)
	    LOOP
		INSERT INTO test (colonne1, colonne2) VALUES (idcol, tableau[i]);
	    END LOOP;
        END;
$$;

Puis je l'ai lancée

SELECT insertion (1, '{1,2,4,5}');

Et j'obtiens bien ma table

colonne 1  |  colonne 2
     1     |     1
     1     |     2
     1     |     4
     1     |     5

Mais je me demande quel est le gain réel et si ça vaut vraiment le coup de se creuser la tête pour adapter cette fonction à mon besoin ci-dessus.

En gros, avec cette fonction, j'envoie une fois pour toute les infos du document avec un array contenant les ID du type de documents, et la fonction créé autant de ligne dans la table documents_types que nécessaire.
Mais quel est réellement le gain par rapport à : créer mon document et récupérer son ID, puis envoyer autant de requête que nécessaire pour créer les lignes de la table documents_types ? La charge réseau ?

De plus, l'avantage des requêtes préparées, c'est qu'elles étaient supprimées à la fermeture de la session utilisateur. Ce qui n'est pas le cas des fonctions...
Je ne sais pas si cela aura des conséquences à terme ...

Merci de vos éclaircissements.

Bonsoir.

Suite et fin de mes pérégrinations.
Je dis fin, car comme Jacques BREL, je n'irai pas plus loin

L'utilisation de la base en tant que stockage de fichier est un échec (dans mon cas). Pour la majeur partie des fichiers, cela se passe bien. A partir d'une taille (grosso merdo 10-15 Mo), le temps de transfert en écriture devient vraiment trop long. Sans parler de la lecture qui impose un téléchargement complet du fichier avant de pouvoir l'ouvrir par l'ActiveX Adobe. L'utilisation via un partage réseau permet de commencer à afficher les premières pages du fichier alors qu'il n'est pas encore complétement chargé = moins de latence pour l'utilisateur.

J'ai installé un service SMB sur mon serveur avec quelques droits bien sentis (bon OK, je me suis fais aider ) et mon application arrive à afficher les fichiers, même les plus gros, dans des délais raisonnables.

Pour des questions de sécurité, les échanges devront être chiffrés, ce qui implique un temps de chargement plus long. Quand je parle des échanges, je parle des échanges au niveau de SMB, mais également au niveau des requêtes SQL (SSL ? SSH ?)

L'idéal pour les fichiers serait un chiffrement/déchiffrement directement réalisé par l'application cliente : même un piratage du serveur ne servirait pas à grand chose dans ce cas. Mais bon, il faut que je regarde ce que ça donne avec les fonctions intégrées à Windev.

En tout cas, merci de votre soutiens, j'ai appris plein de choses grâce à vous.
Cordialement,
Ramirez

Rhaaaa ! Je vais pas y arriver

Bon, café, on va reprendre tout depuis le début.
J'ai du mal à envoyer mes données via une requête SQL par Windev. J'utilise l'argument {WDMemoBinaire('<Fichier>')}pour pouvoir envoyer les données "brutes", mais il se passe quelque chose pendant la com'.

Entête fichier PDF 'conforme' (envoyé par le client)
%PDF-1.6
%Þ­¾ï
6 0 obj
<<  /Length 39463 /Filter /FlateDecode /DecodeParms
<<  /Predictor 1

Entête fichier PDF 'non conforme' (reçu par le serveur)
%PDF-1.6\012%\336\255\276\357\0126 0 obj\012<<  /Length 39463 /Filter /FlateDecode /DecodeParms\012<<  /Predictor 

On voit bien que le fichier a été interprété (CR devient \012 par exemple). De plus, la taille du fichier a quasiment triplée. Le fichier est bien sur illisible.

Du coup, j'ai regardé les types de variables en entrée. pg_file_write demande des données sous forme text alors que j'envoie des données binaires. Il y a peu-être quelque chose à voir là dedans. Mais je ne vois pas comment envoyer mes données autrement que sous la forme binaire avec Windev ...

Il existe bien un pg_read_binary_file(), mais pas l'inverse ...
Je creuse ...

Bonjour,

J'ai testé avec pg_read_binary_file() et pg_file_write(). J'obtiens enfin le bon résultat mais cela nécessite que le rôle qui se connecte aie le privilège de super-utilisateur. Cela me pose des problèmes d'ordre "éthique", car même les administrateurs de l'application n'ont pas ce genre de droits ...

J'ai fais des essais avec external_file et ça marche pas trop mal non plus. Tout se fait via external_file et je n'ai pas de soucis au niveau des droits.
Je vais essayer de repartir sur une base vierge et recommencer afin de valider les manipulations (à force de faire des modifs, on n'est plus trop sur de ce qui fonctionne vraiment ), et surtout de l'implanter dans mon application pour voir si l'intégration ne pose pas de problème (en version stand-alone actuellement).

Pour ceux que ça intéresse :

// Requêtes d'écriture du fichier sur le serveur. %1=fichier à transmettre, %2=nom du fichier de destination
gsRequeteSQL = "SELECT external_file.writeEfile({WDMemoBinaire('%1')}, ('<Répertoire_destination>', '%2'));"

// Complétion de la requête avec les valeurs variables (SAI_fichier = chemin + nom + extension du fichier)
gsRequeteSQL = ChaîneConstruit(gsRequeteSQL, SAI_Fichier, fExtraitChemin(SAI_Fichier,fFichier+fExtension))

// Émission de la requête, traitement de l'erreur
SI SQLExec(gsRequeteSQL,gResultatSQL) = Faux ALORS 
	SQLInfoGene(gResultatSQL)
	Erreur(SQL.MesErreur)
	SQLFerme(gResultatSQL)
SINON
	Info("Envoyé")
FIN

//  -------------------------------------------------------------------------------------------
// Requête de lecture
gsRequeteSQL = "SELECT external_file.readefile(('<Repertoire_destination>', '%1'));"

// Là encore complétion de la requête avec les variables 
gsRequeteSQL = ChaîneConstruit(gsRequeteSQL, fExtraitChemin(SAI_Fichier,fFichier+fExtension))

// Émission de la requête et traitement de l'erreur
SI SQLExec(gsRequeteSQL,gResultatSQL) = Faux ALORS 
	SQLInfoGene(gResultatSQL)
	Erreur(SQL.MesErreur)
	SQLFerme(gResultatSQL)
SINON
	Info("Reçu")
	SQLAvance(gResultatSQL)
// Récupération des valeurs en format binaire et envoi dans l'image à afficher
	IMG_image = SQLLitMémo(gResultatSQL,1)
	SQLFerme(gResultatSQL)
FIN

J'espère que cela pourra aider certaines personnes.

Il ne restera plus qu'à gérer l'effacement des fichiers. En effet, il peut arriver qu'un fichier doive être effacé (obsolescence du fichier, erreur ...). Et là, external_file ne propose pas cette fonction. Il faudra voir si je peux octroyer les droits Super-utilisateur aux administrateur de l'application... A voir.

Bonne soirée.

Merci beaucoup pour ces informations précises et surtout très bien explicitées.
Je n'avais aucune idée de tout ces détails et j'avoue que cela m'éclaire grandement.

Fort de ces explications, et par rapport à l'utilisation que j'en ai, il est désormais évident qu'il vaut mieux partir sur un serveur de fichiers en parallèle de ma base plutôt que d'enregistrer les fichier directement dans celle-ci.
Je suis également en train de creuser l'extension external_file, qui pourrait bien être le meilleur des 2 mondes : le fichier est sauvegardé sur un espace disque "en clair" et PostgreSQL sert de "passerelle" : pas besoin de serveur de fichier (donc pas de ports supplémentaire ouvert etc ...), droits utilisateurs ...

Je teste et vous dit ce qu'il en est. Si par contre vous avez un REX à partager, je suis également preneur.

Bonne nuit.

Bonjour et merci de ce premier retour.

Pas le choix hélas ...

Pas faux, je vais essayer de mettre ça en œuvre, mais je ne sais pas quand ni trop comment pour l'instant Encore un peu de lecture en perspective ...

Je n'ai pas encore de vision claire de la volumétrie, mais je devrais avoir une estimatif grossier assez rapidement. Je reviendrai d'ici peu pour compléter ces infos.

Mais pour compléter ma maigre connaissance de PostgreSQL, pourquoi est-il déconseillé de stocker des données de fichier ?
Pour éviter de surcharger le serveur (pendant qu'il envoie le fichier, il ne peut pas traiter d'autre requête) ? Mais alors dans ce cas, mettre un serveur de fichiers sur le même serveur physique ne va pas changer grand chose (les ressources restent "limitées" aux capacités du serveur physique). Ou est-ce uniquement pour que les opérations de sauvegarde prennent moins de ressources ? D'ailleurs, qu'appelle t'on "opérations de maintenance" ? D'autres tâches que la sauvegarde ?

Désolé si mes questions paraissent bêtes, mais ma spécialité reste l'automatisme industriel alors ...

Merci encore, bonne soirée.