Hello, je fais un insertion dans une table ACCESS où la clef est
générée automatiquement. Le Update se passe bien, par contre je ne sais
pas comment faire pour récupérer la valeur de la clef qui a été générée
par ACCESS. Avez vous une idée?
Cdt
Thierry
PS:
je travaille en DAO
je créer un reccordset sur la table
je fais un add new
puis update.
c'est une fois là que je voudrais récpérer la clef généré
automatiquement....
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Quasimodo
thierry expressed precisely :
Hello, je fais un insertion dans une table ACCESS où la clef est générée automatiquement. Le Update se passe bien, par contre je ne sais pas comment faire pour récupérer la valeur de la clef qui a été générée par ACCESS. Avez vous une idée?
Cdt
Thierry
PS:
je travaille en DAO
je créer un reccordset sur la table je fais un add new puis update.
c'est une fois là que je voudrais récpérer la clef généré automatiquement....
Bonjour, Il existe sur le site msdn un topic la dessus, sorry je ne me souvien plus de l'url. Un bon conseille (je suis passé sur ce problème aussi), n'utilisez pas d'autonumber. Gérer vous même les clefs. Je vais essayer de retrouver l'url.
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
thierry expressed precisely :
Hello, je fais un insertion dans une table ACCESS où la clef est
générée automatiquement. Le Update se passe bien, par contre je ne sais
pas comment faire pour récupérer la valeur de la clef qui a été générée
par ACCESS. Avez vous une idée?
Cdt
Thierry
PS:
je travaille en DAO
je créer un reccordset sur la table
je fais un add new
puis update.
c'est une fois là que je voudrais récpérer la clef généré
automatiquement....
Bonjour,
Il existe sur le site msdn un topic la dessus, sorry je ne me souvien
plus de l'url.
Un bon conseille (je suis passé sur ce problème aussi), n'utilisez pas
d'autonumber. Gérer vous même les clefs.
Je vais essayer de retrouver l'url.
@+Quaz
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Hello, je fais un insertion dans une table ACCESS où la clef est générée automatiquement. Le Update se passe bien, par contre je ne sais pas comment faire pour récupérer la valeur de la clef qui a été générée par ACCESS. Avez vous une idée?
Cdt
Thierry
PS:
je travaille en DAO
je créer un reccordset sur la table je fais un add new puis update.
c'est une fois là que je voudrais récpérer la clef généré automatiquement....
Bonjour, Il existe sur le site msdn un topic la dessus, sorry je ne me souvien plus de l'url. Un bon conseille (je suis passé sur ce problème aussi), n'utilisez pas d'autonumber. Gérer vous même les clefs. Je vais essayer de retrouver l'url.
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
Pascal B.
Salut Thierry,
Il suffit de lire le contenu du champs juste après le AddNew et avant le Update. Exemple:
Dom DB as Database Dim RS as Recordset Dim Cle as Long '... Set RS = DB.OpenRecordset("MaTable") RS.AddNew 'Récupération de la valeur de la clé générée automatiquement Cle = RS!MonChampCle 'Initialisation des autres champs '... RS.Update RS.Close
Pascal B.
"thierry" wrote in message news: | | Hello, je fais un insertion dans une table ACCESS où la clef est | générée automatiquement. Le Update se passe bien, par contre je ne sais | pas comment faire pour récupérer la valeur de la clef qui a été générée | par ACCESS. Avez vous une idée? | | Cdt | | Thierry | | PS: | | je travaille en DAO | | je créer un reccordset sur la table | je fais un add new | puis update. | | c'est une fois là que je voudrais récpérer la clef généré | automatiquement....
Salut Thierry,
Il suffit de lire le contenu du champs juste après le AddNew et avant le Update.
Exemple:
Dom DB as Database
Dim RS as Recordset
Dim Cle as Long
'...
Set RS = DB.OpenRecordset("MaTable")
RS.AddNew
'Récupération de la valeur de la clé générée automatiquement
Cle = RS!MonChampCle
'Initialisation des autres champs
'...
RS.Update
RS.Close
Pascal B.
"thierry" <titi@laposte.net> wrote in message news:GFr.1c17da45a32231179896e8@News.dial.oleane.com...
|
| Hello, je fais un insertion dans une table ACCESS où la clef est
| générée automatiquement. Le Update se passe bien, par contre je ne sais
| pas comment faire pour récupérer la valeur de la clef qui a été générée
| par ACCESS. Avez vous une idée?
|
| Cdt
|
| Thierry
|
| PS:
|
| je travaille en DAO
|
| je créer un reccordset sur la table
| je fais un add new
| puis update.
|
| c'est une fois là que je voudrais récpérer la clef généré
| automatiquement....
Il suffit de lire le contenu du champs juste après le AddNew et avant le Update. Exemple:
Dom DB as Database Dim RS as Recordset Dim Cle as Long '... Set RS = DB.OpenRecordset("MaTable") RS.AddNew 'Récupération de la valeur de la clé générée automatiquement Cle = RS!MonChampCle 'Initialisation des autres champs '... RS.Update RS.Close
Pascal B.
"thierry" wrote in message news: | | Hello, je fais un insertion dans une table ACCESS où la clef est | générée automatiquement. Le Update se passe bien, par contre je ne sais | pas comment faire pour récupérer la valeur de la clef qui a été générée | par ACCESS. Avez vous une idée? | | Cdt | | Thierry | | PS: | | je travaille en DAO | | je créer un reccordset sur la table | je fais un add new | puis update. | | c'est une fois là que je voudrais récpérer la clef généré | automatiquement....
thierry
In article , says...
Salut Thierry,
Il suffit de lire le contenu du champs juste après le AddNew et avant le Update. Exemple:
Dom DB as Database Dim RS as Recordset Dim Cle as Long '... Set RS = DB.OpenRecordset("MaTable") RS.AddNew 'Récupération de la valeur de la clé générée automatiquement Cle = RS!MonChampCle 'Initialisation des autres champs '... RS.Update RS.Close
Pascal B.
"thierry" wrote in message news: | | Hello, je fais un insertion dans une table ACCESS où la clef est | générée automatiquement. Le Update se passe bien, par contre je ne sais | pas comment faire pour récupérer la valeur de la clef qui a été générée | par ACCESS. Avez vous une idée? | | Cdt | | Thierry | | PS: | | je travaille en DAO | | je créer un reccordset sur la table | je fais un add new | puis update. | | c'est une fois là que je voudrais récpérer la clef généré | automatiquement....
super génial, ça marche
MERCI BEAUCOUP
cordialement
Thierry
In article <uCxv2h61EHA.2644@TK2MSFTNGP11.phx.gbl>,
Pascbr@hotmail_ANTISPASM_.com says...
Salut Thierry,
Il suffit de lire le contenu du champs juste après le AddNew et avant le Update.
Exemple:
Dom DB as Database
Dim RS as Recordset
Dim Cle as Long
'...
Set RS = DB.OpenRecordset("MaTable")
RS.AddNew
'Récupération de la valeur de la clé générée automatiquement
Cle = RS!MonChampCle
'Initialisation des autres champs
'...
RS.Update
RS.Close
Pascal B.
"thierry" <titi@laposte.net> wrote in message news:GFr.1c17da45a32231179896e8@News.dial.oleane.com...
|
| Hello, je fais un insertion dans une table ACCESS où la clef est
| générée automatiquement. Le Update se passe bien, par contre je ne sais
| pas comment faire pour récupérer la valeur de la clef qui a été générée
| par ACCESS. Avez vous une idée?
|
| Cdt
|
| Thierry
|
| PS:
|
| je travaille en DAO
|
| je créer un reccordset sur la table
| je fais un add new
| puis update.
|
| c'est une fois là que je voudrais récpérer la clef généré
| automatiquement....
Il suffit de lire le contenu du champs juste après le AddNew et avant le Update. Exemple:
Dom DB as Database Dim RS as Recordset Dim Cle as Long '... Set RS = DB.OpenRecordset("MaTable") RS.AddNew 'Récupération de la valeur de la clé générée automatiquement Cle = RS!MonChampCle 'Initialisation des autres champs '... RS.Update RS.Close
Pascal B.
"thierry" wrote in message news: | | Hello, je fais un insertion dans une table ACCESS où la clef est | générée automatiquement. Le Update se passe bien, par contre je ne sais | pas comment faire pour récupérer la valeur de la clef qui a été générée | par ACCESS. Avez vous une idée? | | Cdt | | Thierry | | PS: | | je travaille en DAO | | je créer un reccordset sur la table | je fais un add new | puis update. | | c'est une fois là que je voudrais récpérer la clef généré | automatiquement....
super génial, ça marche
MERCI BEAUCOUP
cordialement
Thierry
jmn
Version 1 : la propriété lastmodified du recordset retourne un bookmark sur le dernier enregistrement modifié/créé
Version 2 : un "select top 1 * from table order by compteur desc" permet de retrouver le dernier enregistrement si : compteur est en incrément automatique et pas en aléatoire, et si vous avez un index dessus (si + milliers d'enr).
Tout cela suppose que vous soyez à peu près certain qu'à un instant donné (quelques secondes) il n'y ai qu'un seul utilisateur qui soit en train de créer un enregistrement dans la table. Sinon, rajoutez des critères à la version 2 (sur ce qui vient d'être saisi ou des données relatives au contexte) pour être sûr de retrouver le bon enr : "select top 1 * from table where truc='" & dat(0) & "' and machin ='" & dat(25) & "' order by compteur desc" Prenons l'exemple d'une saisie de ligne de facture. Il peut bien avoir 150 utilisateurs en train de saisir des lignes, mais chacun travaille dans sa facture. Donc, retrouver la plus grande valeur de 'compteur' pour les lignes saisies en référence de LA facture 3213213 retourne bien l'enr. voulu.
(accessoirement, après un .addnew le pointeur de lecture du recordset reste là où il était avant...)
Version 1 : la propriété lastmodified du recordset retourne un bookmark sur
le dernier enregistrement modifié/créé
Version 2 : un "select top 1 * from table order by compteur desc" permet de
retrouver le dernier enregistrement si : compteur est en incrément
automatique et pas en aléatoire, et si vous avez un index dessus (si +
milliers d'enr).
Tout cela suppose que vous soyez à peu près certain qu'à un instant donné
(quelques secondes) il n'y ai qu'un seul utilisateur qui soit en train de
créer un enregistrement dans la table. Sinon, rajoutez des critères à la
version 2 (sur ce qui vient d'être saisi ou des données relatives au
contexte) pour être sûr de retrouver le bon enr :
"select top 1 * from table where truc='" & dat(0) & "' and machin ='" &
dat(25) & "' order by compteur desc"
Prenons l'exemple d'une saisie de ligne de facture. Il peut bien avoir 150
utilisateurs en train de saisir des lignes, mais chacun travaille dans sa
facture. Donc, retrouver la plus grande valeur de 'compteur' pour les lignes
saisies en référence de LA facture 3213213 retourne bien l'enr. voulu.
(accessoirement, après un .addnew le pointeur de lecture du recordset reste
là où il était avant...)
Version 1 : la propriété lastmodified du recordset retourne un bookmark sur le dernier enregistrement modifié/créé
Version 2 : un "select top 1 * from table order by compteur desc" permet de retrouver le dernier enregistrement si : compteur est en incrément automatique et pas en aléatoire, et si vous avez un index dessus (si + milliers d'enr).
Tout cela suppose que vous soyez à peu près certain qu'à un instant donné (quelques secondes) il n'y ai qu'un seul utilisateur qui soit en train de créer un enregistrement dans la table. Sinon, rajoutez des critères à la version 2 (sur ce qui vient d'être saisi ou des données relatives au contexte) pour être sûr de retrouver le bon enr : "select top 1 * from table where truc='" & dat(0) & "' and machin ='" & dat(25) & "' order by compteur desc" Prenons l'exemple d'une saisie de ligne de facture. Il peut bien avoir 150 utilisateurs en train de saisir des lignes, mais chacun travaille dans sa facture. Donc, retrouver la plus grande valeur de 'compteur' pour les lignes saisies en référence de LA facture 3213213 retourne bien l'enr. voulu.
(accessoirement, après un .addnew le pointeur de lecture du recordset reste là où il était avant...)
thierry
In article , says...
Version 1 : la propriété lastmodified du recordset retourne un bookmark sur le dernier enregistrement modifié/créé
Version 2 : un "select top 1 * from table order by compteur desc" permet de retrouver le dernier enregistrement si : compteur est en incrément automatique et pas en aléatoire, et si vous avez un index dessus (si + milliers d'enr).
Tout cela suppose que vous soyez à peu près certain qu'à un instant donné (quelques secondes) il n'y ai qu'un seul utilisateur qui soit en train de créer un enregistrement dans la table. Sinon, rajoutez des critères à la version 2 (sur ce qui vient d'être saisi ou des données relatives au contexte) pour être sûr de retrouver le bon enr : "select top 1 * from table where truc='" & dat(0) & "' and machin ='" & dat(25) & "' order by compteur desc" Prenons l'exemple d'une saisie de ligne de facture. Il peut bien avoir 150 utilisateurs en train de saisir des lignes, mais chacun travaille dans sa facture. Donc, retrouver la plus grande valeur de 'compteur' pour les lignes saisies en référence de LA facture 3213213 retourne bien l'enr. voulu.
(accessoirement, après un .addnew le pointeur de lecture du recordset reste là où il était avant...)
je profite de votre réponse pour rebondir sur une question qui me titille depuis un certain temps.
Quand je bossais sur la base de données Ingres avec l'outil OPEN ROAD, nous gérions nos clef nous mêmes. Pour cela, on indiquait explicitement que nous posions un verrrou exclusif sur une table, puis nous débutions notre transaction (en écrivant set autocommit off), nous faisions une série de transaction sur plusieurs tables et si tout se passait bien, nous faisions un commit ou sinon un rollback.
En VB, je peux poser des verrous au niveau du Recordset, mais je ne sais pas comment pas comment gérer le commit ou le rollback, dan sle cas de plusieurs transactions. Avez vous une idée? Je pense que le commit est géré par le update du reccordset...
In article <OEWvRG71EHA.3324@tk2msftngp13.phx.gbl>, jmn@truc.com says...
Version 1 : la propriété lastmodified du recordset retourne un bookmark sur
le dernier enregistrement modifié/créé
Version 2 : un "select top 1 * from table order by compteur desc" permet de
retrouver le dernier enregistrement si : compteur est en incrément
automatique et pas en aléatoire, et si vous avez un index dessus (si +
milliers d'enr).
Tout cela suppose que vous soyez à peu près certain qu'à un instant donné
(quelques secondes) il n'y ai qu'un seul utilisateur qui soit en train de
créer un enregistrement dans la table. Sinon, rajoutez des critères à la
version 2 (sur ce qui vient d'être saisi ou des données relatives au
contexte) pour être sûr de retrouver le bon enr :
"select top 1 * from table where truc='" & dat(0) & "' and machin ='" &
dat(25) & "' order by compteur desc"
Prenons l'exemple d'une saisie de ligne de facture. Il peut bien avoir 150
utilisateurs en train de saisir des lignes, mais chacun travaille dans sa
facture. Donc, retrouver la plus grande valeur de 'compteur' pour les lignes
saisies en référence de LA facture 3213213 retourne bien l'enr. voulu.
(accessoirement, après un .addnew le pointeur de lecture du recordset reste
là où il était avant...)
je profite de votre réponse pour rebondir sur une question qui me
titille depuis un certain temps.
Quand je bossais sur la base de données Ingres avec l'outil OPEN ROAD,
nous gérions nos clef nous mêmes. Pour cela, on indiquait explicitement
que nous posions un verrrou exclusif sur une table, puis nous débutions
notre transaction (en écrivant set autocommit off), nous faisions une
série de transaction sur plusieurs tables et si tout se passait bien,
nous faisions un commit ou sinon un rollback.
En VB, je peux poser des verrous au niveau du Recordset, mais je ne sais
pas comment pas comment gérer le commit ou le rollback, dan sle cas de
plusieurs transactions. Avez vous une idée? Je pense que le commit est
géré par le update du reccordset...
Version 1 : la propriété lastmodified du recordset retourne un bookmark sur le dernier enregistrement modifié/créé
Version 2 : un "select top 1 * from table order by compteur desc" permet de retrouver le dernier enregistrement si : compteur est en incrément automatique et pas en aléatoire, et si vous avez un index dessus (si + milliers d'enr).
Tout cela suppose que vous soyez à peu près certain qu'à un instant donné (quelques secondes) il n'y ai qu'un seul utilisateur qui soit en train de créer un enregistrement dans la table. Sinon, rajoutez des critères à la version 2 (sur ce qui vient d'être saisi ou des données relatives au contexte) pour être sûr de retrouver le bon enr : "select top 1 * from table where truc='" & dat(0) & "' and machin ='" & dat(25) & "' order by compteur desc" Prenons l'exemple d'une saisie de ligne de facture. Il peut bien avoir 150 utilisateurs en train de saisir des lignes, mais chacun travaille dans sa facture. Donc, retrouver la plus grande valeur de 'compteur' pour les lignes saisies en référence de LA facture 3213213 retourne bien l'enr. voulu.
(accessoirement, après un .addnew le pointeur de lecture du recordset reste là où il était avant...)
je profite de votre réponse pour rebondir sur une question qui me titille depuis un certain temps.
Quand je bossais sur la base de données Ingres avec l'outil OPEN ROAD, nous gérions nos clef nous mêmes. Pour cela, on indiquait explicitement que nous posions un verrrou exclusif sur une table, puis nous débutions notre transaction (en écrivant set autocommit off), nous faisions une série de transaction sur plusieurs tables et si tout se passait bien, nous faisions un commit ou sinon un rollback.
En VB, je peux poser des verrous au niveau du Recordset, mais je ne sais pas comment pas comment gérer le commit ou le rollback, dan sle cas de plusieurs transactions. Avez vous une idée? Je pense que le commit est géré par le update du reccordset...
jmn
Les transactions sont gérées dans VB à travers des méthodes associées au moteur de GBD utilisé. Les méthodes sont BeginTrans, CommitTrans, Rollback(trans) (rollback avec DAO, rollbacktrans avec ADO)
Avec DAO, le moteur Jet réalise les opérations en local ( fichiers dans temp) et, en cas de succès, il transfère les résultats dans la base réelle. En pratique, cela ne marche pas bien car la base est lockée en totalité pendant toutes la manoeuvre et il n'y a pas de gestion centralisée qui permettent de régler les conflits sur plusieurs transactions issues de postes différents qui se lanceraient 'à peu près' en même temps. De plus, lemoteur Jet a tendance à se prendre les pieds dans sa gestion des fichiers TEMP (avec une grosse appli DAO il faut toujours commencer par vider temp...) ! Mon expérience montre qu'avec DAO il est moins risqué de traiter le problème par du code que de le sous-traiter à DAO.
Avec ADO et SQL Server (par exemple) les requêtes sont controlées et journalisées au niveau du serveur, et ca marche très bien.
Les transactions sont gérées dans VB à travers des méthodes associées au
moteur de GBD utilisé.
Les méthodes sont BeginTrans, CommitTrans, Rollback(trans) (rollback avec
DAO, rollbacktrans avec ADO)
Avec DAO, le moteur Jet réalise les opérations en local ( fichiers dans
temp) et, en cas de succès, il transfère les résultats dans la base réelle.
En pratique, cela ne marche pas bien car la base est lockée en totalité
pendant toutes la manoeuvre et il n'y a pas de gestion centralisée qui
permettent de régler les conflits sur plusieurs transactions issues de
postes différents qui se lanceraient 'à peu près' en même temps. De plus,
lemoteur Jet a tendance à se prendre les pieds dans sa gestion des fichiers
TEMP (avec une grosse appli DAO il faut toujours commencer par vider
temp...) ! Mon expérience montre qu'avec DAO il est moins risqué de traiter
le problème par du code que de le sous-traiter à DAO.
Avec ADO et SQL Server (par exemple) les requêtes sont controlées et
journalisées au niveau du serveur, et ca marche très bien.
Les transactions sont gérées dans VB à travers des méthodes associées au moteur de GBD utilisé. Les méthodes sont BeginTrans, CommitTrans, Rollback(trans) (rollback avec DAO, rollbacktrans avec ADO)
Avec DAO, le moteur Jet réalise les opérations en local ( fichiers dans temp) et, en cas de succès, il transfère les résultats dans la base réelle. En pratique, cela ne marche pas bien car la base est lockée en totalité pendant toutes la manoeuvre et il n'y a pas de gestion centralisée qui permettent de régler les conflits sur plusieurs transactions issues de postes différents qui se lanceraient 'à peu près' en même temps. De plus, lemoteur Jet a tendance à se prendre les pieds dans sa gestion des fichiers TEMP (avec une grosse appli DAO il faut toujours commencer par vider temp...) ! Mon expérience montre qu'avec DAO il est moins risqué de traiter le problème par du code que de le sous-traiter à DAO.
Avec ADO et SQL Server (par exemple) les requêtes sont controlées et journalisées au niveau du serveur, et ca marche très bien.
thierry
In article <#KHN#, says...
Les transactions sont gérées dans VB à travers des méthodes associées au moteur de GBD utilisé. Les méthodes sont BeginTrans, CommitTrans, Rollback(trans) (rollback avec DAO, rollbacktrans avec ADO)
Avec DAO, le moteur Jet réalise les opérations en local ( fichiers dans temp) et, en cas de succès, il transfère les résultats dans la base réelle. En pratique, cela ne marche pas bien car la base est lockée en totalité pendant toutes la manoeuvre et il n'y a pas de gestion centralisée qui permettent de régler les conflits sur plusieurs transactions issues de postes différents qui se lanceraient 'à peu près' en même temps. De plus, lemoteur Jet a tendance à se prendre les pieds dans sa gestion des fichiers TEMP (avec une grosse appli DAO il faut toujours commencer par vider temp...) ! Mon expérience montre qu'avec DAO il est moins risqué de traiter le problème par du code que de le sous-traiter à DAO.
Avec ADO et SQL Server (par exemple) les requêtes sont controlées et journalisées au niveau du serveur, et ca marche très bien.
ok, moi je bosse avec ACESSS, par contre, dès que j'ai terminé mon appli, je vais utiliser ADO à la place de DAO. Est ce que cela sera mieux?
In article <#KHN#HF2EHA.3120@TK2MSFTNGP12.phx.gbl>, jmn@truc.com says...
Les transactions sont gérées dans VB à travers des méthodes associées au
moteur de GBD utilisé.
Les méthodes sont BeginTrans, CommitTrans, Rollback(trans) (rollback avec
DAO, rollbacktrans avec ADO)
Avec DAO, le moteur Jet réalise les opérations en local ( fichiers dans
temp) et, en cas de succès, il transfère les résultats dans la base réelle.
En pratique, cela ne marche pas bien car la base est lockée en totalité
pendant toutes la manoeuvre et il n'y a pas de gestion centralisée qui
permettent de régler les conflits sur plusieurs transactions issues de
postes différents qui se lanceraient 'à peu près' en même temps. De plus,
lemoteur Jet a tendance à se prendre les pieds dans sa gestion des fichiers
TEMP (avec une grosse appli DAO il faut toujours commencer par vider
temp...) ! Mon expérience montre qu'avec DAO il est moins risqué de traiter
le problème par du code que de le sous-traiter à DAO.
Avec ADO et SQL Server (par exemple) les requêtes sont controlées et
journalisées au niveau du serveur, et ca marche très bien.
ok,
moi je bosse avec ACESSS, par contre, dès que j'ai terminé mon appli, je
vais utiliser ADO à la place de DAO. Est ce que cela sera mieux?
Les transactions sont gérées dans VB à travers des méthodes associées au moteur de GBD utilisé. Les méthodes sont BeginTrans, CommitTrans, Rollback(trans) (rollback avec DAO, rollbacktrans avec ADO)
Avec DAO, le moteur Jet réalise les opérations en local ( fichiers dans temp) et, en cas de succès, il transfère les résultats dans la base réelle. En pratique, cela ne marche pas bien car la base est lockée en totalité pendant toutes la manoeuvre et il n'y a pas de gestion centralisée qui permettent de régler les conflits sur plusieurs transactions issues de postes différents qui se lanceraient 'à peu près' en même temps. De plus, lemoteur Jet a tendance à se prendre les pieds dans sa gestion des fichiers TEMP (avec une grosse appli DAO il faut toujours commencer par vider temp...) ! Mon expérience montre qu'avec DAO il est moins risqué de traiter le problème par du code que de le sous-traiter à DAO.
Avec ADO et SQL Server (par exemple) les requêtes sont controlées et journalisées au niveau du serveur, et ca marche très bien.
ok, moi je bosse avec ACESSS, par contre, dès que j'ai terminé mon appli, je vais utiliser ADO à la place de DAO. Est ce que cela sera mieux?
jmn
Fondamentalement, cela ne change rien... DAO et ADO ne sont que des interfaces entre le programme et les moteurs de gestion. Pour un fonctionnement parfaitement sûr, et par principe même, choisissez un sgbd client/serveur (oracle, sql server, db2, etc...) ou, si vous y tenez absolument, bricolez un module centralisé avec Access pour le faire tourner en client/serveur (des exemples existes sur le web et sur msdn.microsoft.com). Maintenant, s'il s'agit d'une application légère avec un nombre de postes réduits, ne vous cassez pas la tête et continuez avec Access (si possible dans une version supérieure ou égale à 2000, cela réduit les risques...).
Fondamentalement, cela ne change rien... DAO et ADO ne sont que des
interfaces entre le programme et les moteurs de gestion.
Pour un fonctionnement parfaitement sûr, et par principe même, choisissez un
sgbd client/serveur (oracle, sql server, db2, etc...) ou, si vous y tenez
absolument, bricolez un module centralisé avec Access pour le faire tourner
en client/serveur (des exemples existes sur le web et sur
msdn.microsoft.com).
Maintenant, s'il s'agit d'une application légère avec un nombre de postes
réduits, ne vous cassez pas la tête et continuez avec Access (si possible
dans une version supérieure ou égale à 2000, cela réduit les risques...).
Fondamentalement, cela ne change rien... DAO et ADO ne sont que des interfaces entre le programme et les moteurs de gestion. Pour un fonctionnement parfaitement sûr, et par principe même, choisissez un sgbd client/serveur (oracle, sql server, db2, etc...) ou, si vous y tenez absolument, bricolez un module centralisé avec Access pour le faire tourner en client/serveur (des exemples existes sur le web et sur msdn.microsoft.com). Maintenant, s'il s'agit d'une application légère avec un nombre de postes réduits, ne vous cassez pas la tête et continuez avec Access (si possible dans une version supérieure ou égale à 2000, cela réduit les risques...).
