PureBasic

Bonjour,

Je viens de me reposer une question qui me gênais depuis mes débuts avec PB (il y a 2,5 ans ).
C'est l'absence de fichier à accès direct ! Style PowerBasic, QB, QBX ou autre Pascal, etc...

Comme les réponses on été souvent de type pourquoi s'emm... avec ça quand tu peux lire un fichier entier (même gros) en une fois. Et que une fois lu c'est tellement plus rapide en mémoire ! Hein ? Et c'est vrai, sauf que !

Ben, aujourd'hui je sais pourquoi ça me gênais (hé, oui je me fais vieux et il m'a fallu le temps !).
Hé bien, ce n'étais pas seulement pour récupérer des anciens codes, mais surtout (et c'est de ça qu'il est question surtout) :

Comment verrouiller UN enregistrement dans un fichier au moment ou l'on travaille dessus quand on est en réseau...

Il faut nécessairement laisser le fichier accessible à tous c'est-à-dire sur disque, et en plus il ne s'agit pas de bloquer le fichier, mais seulement l'enregistrement sur lequel on travaille et ce quand une dizaine de personnes ou plus sont susceptible de travailler sur le même fichier et de vouloir par hasard accéder à CETenregistrement là en même temps ?

Avant, j'avais deux commandes (instruction), Lock et Unlock... Qui me permettais de verrouiller l'enregistrement et interdisait tout accès tant que le premier qui l'avais appelé l'utilisait et qu'il n'était libéré qu'au moment ou il en avait finit et devenais donc disponible pour le suivant.
Ce qui est la seule garantie pour que le travaille de l'un n'écrase pas celui de l'autre. Qu'une modification ou évolution soit prise en compte etc.

Bref , Jusque maintenant, je n'ai pas vue ni entendu parler de possibilité du genre (et ne m'en suis d'ailleurs pas trop préoccupé), mais je viens de démarrer un projet qui nécessite ce genre d'approche, et forcément la réflexion me fait retomber sur cette question.

Précision, je ne tiens pas à utiliser les systèmes de gestion de base de donnée type SQL, MySQL ou OBDC. Cela pour de simple raisons qui sont que je préfère rester maître de mon système de gestion de fichier que je peux à la limite réécrire ! J'ai un ISAM perso, qui demande à être adapté mais reste la question du verrouillage... ?

J'ai bien une idée de comment faire, mais avant de m'y engager, peut-être il existe quelque chose qui m'aurait échappé et que la question serait déjà solutionnée.

OU MIEUX, que la notion de fichier a accès direct (Random Acces) avec LOCK et UNLOCK soit implanté dans PureBasic….

Voilà, voilà... Je ne sais pas si cela à déjà été évoqué, résolus ni ce que vous en pensez ?
Gerhard (GeBonet)

Je ne sais pas sir je vais dire une betise mais bon
Il me semble que quand tu ouvres ton fichier avec la commande openfile, il y a que toi qui peut ecrire donc enregistrer.
Tant que tu n'as pas fait de closefile personne peut le modifier après je pense que 'lon peux y acceder mais en lecture seul
++

Va sous Linux, ta réponse est déjà intégré au noyau!

Merci de la réponse,

Le psychopathe a écrit :Je ne sais pas sir je vais dire une betise mais bon
Il me semble que quand tu ouvres ton fichier avec la commande openfile, il y a que toi qui peut ecrire donc enregistrer.
Tant que tu n'as pas fait de closefile personne peut le modifier après je pense que 'lon peux y acceder mais en lecture seul
++

Mais, c'est justement le problème. Quand on travaille sur plusieurs postes qui travaille sur des mêmes dossiers et mêmes fichiers, on DOIT pouvoir gérer ça, pas seulement en bloquant tout le fichier, ça c'est facile. Mais à l'enregistrement près... Et en Lecture/écriture !

Soit ce que faisait et fait encore l'instruction LOCK et UNLOCK d'autres langages !

J'accède à la fiche "X" du fichier "Personnel" pendant que mon voisin lui va travailler sur "Z" du même fichier "Personnel" et comme par hasard, un autre collègue, va lui vouloir lui aussi accéder à la fiche "X" pour mettre à jours un élément de cette fiche dont lui seul s'occupe mais fait partie du corps cette même fiche. Alors lui ne doit pas pouvoir y accéder. Par contre celui qui va utiliser "Z", pas de problème, lui il doit pouvoir le faire.

@Warkering
C'est possible, mais cela m'étonnerais que PB dispose d'un accès direct sous Linux différent que celui sous Mac ou Windows ?

Ne pas vous trompez, je sais que l'on a un accès direct à n'importe quel byte d'un fichier et de lire les "N" byte que constituerais l'enregistrement... Ce que je déplore c'est que pendant que je traite ces "N" bytes, je ne puisse pas par une instruction "LOCK" quiconque d'y accéder, jusqu'à ce qu'il soient libérer APRÈS le "UNLOCK" et seulement ceux là ! Celà pour laisser l'accès de tout le reste du fichier à tout qui aurait besoin de travailler dessus.
C'est le principe des fichiers multitâches en réseaux !
Merci.

peut-être là

...
It seems Windows is offering a ReadWrite lock called Slim Reader/
Writer (SRW) Locks... but the doc says only Windows Vista or Windows
Server 2008 have this API.
...

There is in kernel mode; not in user-mode. You have to roll your own. You can take a look at the pthread-win32 read/write mutex implementation. Our you can play around with my experimental implementation here:

http://webpages.charter.net/appcore/mis ... n_hpp.html

et là
http://doc.trolltech.com/qq/qq11-mutex.html

pat

@pat
Merci, c'est peut-être une voie à explorer. Et de toute façons à la base, c'est effectivement l'OS qui en tant que serveur, doit bloquer ou débloquer les accès aux fichiers et donc des données sous quelques forme qu'elles soient.

D'où probablement la difficulté pour les développeurs de PB de gérer une commande du type LOCK et UNLOCK qui doivent être des espèces entre guillemets "interface" avec le serveur et rester actif pendant le verrouillage.

En attendant, j'ai une solution, pour résoudre ce problème,mais si j'ai placé ce sujet ici, c'est bien pour prêcher pour obtenir ces instructions permettant de gérer des fichiers en "MultiTâche".

Une de mes solutions serait :
Que tout les fichiers que je traiterais aurons une zone "0" de "x" bytes réservés pour des infos "système" qui pourrait contenir entre autre : "du byte x au byte y, c'est actuellement verrouillé". Que tout mes programmes accédant à mes fichiers doivent juste avant d'accéder à une zone vérifier si cette zone du fichier est disponible ou non. Et bien évidement que l'ensemble de ces fichiers ne seraient accessibles que par ceux qui ont le droit d'y accéder et utilisant ces programmes là !

C'est en gros toute cette gestions à mettre en place qui ne serait pas utile si on disposait de ces "LOCK" et "UNLOCK" qu'il suffirait d'invoquer au moment ou on veux accéder à l'enregistrement... Ou il suffirait de "Get #File, NumEnregistre, LOCK" fait la lecture, verrouille pour les autres. Puis ayant terminé un "Put #File, NumEnregistre, UNLOCK"... Déverrouille l'enregistrement (A la mode PB évidement).

La dessus, merci, et je vais voir ce que raconte les APIs...

Gerhard

il me semble que lorsqu'un prg purebasic ecrit un fichiers
ce fichier est bloqué en acces par Windows pour les autres prg ....

j'ai eu le cas pour mon synthe vocal,
mon synthé vocale genere une phrase sonore a partir d'échantillon sonore
je genere un MP3 , juste avant lecture....

ce MP3 a besoin d'avoir un nom avec un chiffre randomizé , sinon tant que le fichier MP3 n'était pas libéré par mon PRG synthe vocale (une dll)
je ne pouvais en ecrire un autre ayant le meme nom !!, d'où plantage

depuis que je genere mon fichier avec des noms aléatoires, ça fonctionne !

c'est bien que Windows empeche l'acces a un fichier en cours d'ecriture ..
mais n'empeche pas l'acces par plusieurs prg , d'un fichier en Lecture...
ce qui est normale

d'ailleurs il existe un utilitaire pour justement Débloquer les fichiers bloqué (protègé) par Windows
ça s'appelle UNLOCKER
http://logiciels.branchez-vous.com/arch ... our_d.html



maintenant ton histoire d'acces a une partie de fichier
c'est une sorte de Sheduler, d'ORDONNANCER , bref pa évident a mettre en oeuvre

je prefere me reposer sur le blocage fourni par windows !
Tant qu'un fichier est en train d'etre ecrit, personne ne peut y acceder de toute façon !

C'est comme je l'ai dit : un fichier ouvert sous Windows ne peut être utiliser autre qu'en lecture par les autres programmes. Sous Linux, plusieurs programmes peuvent écrire dans un fichier en même temps. C'est pourquoi les protocole comme Git et tous les autres sont sous serveur Linux. Sous Windows, par contre, je n'ai jamais pu le libérer un fichier en cours d'utilisation. C'est particulièrement frustrant lorsque Windows décident de garder en mémoire la DLL que tu veux sacrer à dump!

@Warkering
Il y a une quinzaine d'années, lorsque je faisais du dev pour une boite, on utilisant un générateur d'applications (que personne connait : "Yes You Can"), il y avait cette fonction qui permettait de locker/unlocker un enregistrement et cela tournait pourtant sous Dos 6.22

@GeBonet
Concernant la fonction de lock pour +sieurs utilisateurs, je serais plutôt d'avis d'utiliser une file d'attente, c'est à dire que le 1er qui commence à écrire sur la base est le 1er servi, les autres seraient inscrits dans une file d'attente (géré au niveau du serveur) et dès libération du flux par le 1er, le second acquiert l'attribut d'écriture exclusive sur le fichier avant de libérer cet accès après écriture (et aussi de sortir de la liste d'attente), et ainsi de suite ...

GeBonet a écrit :J'accède à la fiche "X" du fichier "Personnel" pendant que mon voisin lui va travailler sur "Z" du même fichier "Personnel" et comme par hasard, un autre collègue, va lui vouloir lui aussi accéder à la fiche "X" pour mettre à jours un élément de cette fiche dont lui seul s'occupe mais fait partie du corps cette même fiche. Alors lui ne doit pas pouvoir y accéder. Par contre celui qui va utiliser "Z", pas de problème, lui il doit pouvoir le faire.

Si c'est de bases de données dont tu parles, tu pourrais utiliser des bases de données Comme MySQL ou PostGreSQL ? tu n'aurais plus de question à te poser.

GeBonet a écrit :OU MIEUX, que la notion de fichier a accès direct (Random Acces) avec LOCK et UNLOCK soit implanté dans PureBasic….

100/100 d'accord avec toi.

@ falsam
Ce genre de fichiers pour des applications simples (style carnet d'adresse), sont bien plus souple et rapide que les bases de données. Ce serait un ++ pour PB

Je vais peut-être dire une connerie mais...

Si tu mettais en place une technologie client-serveur? Par exemple le prog serveur gère tout seul les accès et met en attente une secondes requête d'un client sur un enregistrement déjà en cours d'utilisation. En plus ça optimise les accès en réseau tout en sécurisant ta base de données en prime.

Bon, c'est vrai que ça nécessite de faire deux applis avec une connexion TCP mais ça peut être agréable à coder.

gildev a écrit :Je vais peut-être dire une connerie mais...

Si tu mettais en place une technologie client-serveur? Par exemple le prog serveur gère tout seul les accès et met en attente une secondes requête d'un client sur un enregistrement déjà en cours d'utilisation. En plus ça optimise les accès en réseau tout en sécurisant ta base de données en prime.

Bon, c'est vrai que ça nécessite de faire deux applis avec une connexion TCP mais ça peut être agréable à coder.

c'est pas une connerie c'est ce que j'ai indiqué plus haut dans ma réponse (en des termes peut-être plus obscurs)

Pourquoi faire simple quant on peu faire compliquer

Oups! Désolé flaith, c'est moi qui ai zapé ta réponse, le matin au taf j'ai un peu de mal.
En gros ma réponse du coup est presque un copier-coller de la tienne.

PS: J'avais prévenu que j'allais dire une connerie.