Je travail sous Access 2003 (office update effectué) avec des tables liees
sous 2000 serveur sql.
Mon probleme est que quand j'essai de modifier des données de ma table, que
se soit par formulaires ou par requete ou bien directement dans ma table, a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je suis
seul a utiliser cette base car elle est toujours en cours de developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de probleme.
Je ne trouve pas de solution a ce probleme extraiement genant.
Merci d'avance a tous le monde
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
didier TEST
"bambi" a écrit dans le message de news:
Bonjour,
Je travail sous Access 2003 (office update effectué) avec des tables liees sous 2000 serveur sql. Mon probleme est que quand j'essai de modifier des données de ma table, que
se soit par formulaires ou par requete ou bien directement dans ma table, a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je suis
seul a utiliser cette base car elle est toujours en cours de developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de probleme.
Je ne trouve pas de solution a ce probleme extraiement genant. Merci d'avance a tous le monde
Bonjour, tu as pensé aux droits d'acces de SQL server ??? le plus simple , dans mon cas , dans access utilisé l'authentification courante et dans SQLserver ajouter les users NT sur ta base / table et cliquez les petites case qui vont bien !
DJ
"bambi" <bambi@discussions.microsoft.com> a écrit dans le message de
news:A6176A9F-2BF3-42F3-B2B6-B99973EFB20D@microsoft.com...
Bonjour,
Je travail sous Access 2003 (office update effectué) avec des tables liees
sous 2000 serveur sql.
Mon probleme est que quand j'essai de modifier des données de ma table,
que
se soit par formulaires ou par requete ou bien directement dans ma table,
a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je
suis
seul a utiliser cette base car elle est toujours en cours de
developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de
probleme.
Je ne trouve pas de solution a ce probleme extraiement genant.
Merci d'avance a tous le monde
Bonjour,
tu as pensé aux droits d'acces de SQL server ???
le plus simple , dans mon cas , dans access utilisé l'authentification
courante et dans SQLserver ajouter les users NT
sur ta base / table et cliquez les petites case qui vont bien !
Je travail sous Access 2003 (office update effectué) avec des tables liees sous 2000 serveur sql. Mon probleme est que quand j'essai de modifier des données de ma table, que
se soit par formulaires ou par requete ou bien directement dans ma table, a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je suis
seul a utiliser cette base car elle est toujours en cours de developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de probleme.
Je ne trouve pas de solution a ce probleme extraiement genant. Merci d'avance a tous le monde
Bonjour, tu as pensé aux droits d'acces de SQL server ??? le plus simple , dans mon cas , dans access utilisé l'authentification courante et dans SQLserver ajouter les users NT sur ta base / table et cliquez les petites case qui vont bien !
DJ
bambi
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
"bambi" a écrit dans le message de news:
Bonjour,
Je travail sous Access 2003 (office update effectué) avec des tables liees sous 2000 serveur sql. Mon probleme est que quand j'essai de modifier des données de ma table, que
se soit par formulaires ou par requete ou bien directement dans ma table, a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je suis
seul a utiliser cette base car elle est toujours en cours de developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de probleme.
Je ne trouve pas de solution a ce probleme extraiement genant. Merci d'avance a tous le monde
Bonjour, tu as pensé aux droits d'acces de SQL server ??? le plus simple , dans mon cas , dans access utilisé l'authentification courante et dans SQLserver ajouter les users NT sur ta base / table et cliquez les petites case qui vont bien !
DJ
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows.
L'utilisateur que j'utilise est considere comme dbo dans sql.
Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant
dans les tables.
"bambi" <bambi@discussions.microsoft.com> a écrit dans le message de
news:A6176A9F-2BF3-42F3-B2B6-B99973EFB20D@microsoft.com...
Bonjour,
Je travail sous Access 2003 (office update effectué) avec des tables liees
sous 2000 serveur sql.
Mon probleme est que quand j'essai de modifier des données de ma table,
que
se soit par formulaires ou par requete ou bien directement dans ma table,
a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je
suis
seul a utiliser cette base car elle est toujours en cours de
developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de
probleme.
Je ne trouve pas de solution a ce probleme extraiement genant.
Merci d'avance a tous le monde
Bonjour,
tu as pensé aux droits d'acces de SQL server ???
le plus simple , dans mon cas , dans access utilisé l'authentification
courante et dans SQLserver ajouter les users NT
sur ta base / table et cliquez les petites case qui vont bien !
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
"bambi" a écrit dans le message de news:
Bonjour,
Je travail sous Access 2003 (office update effectué) avec des tables liees sous 2000 serveur sql. Mon probleme est que quand j'essai de modifier des données de ma table, que
se soit par formulaires ou par requete ou bien directement dans ma table, a
chaque fois il me dit que j'ai un conflit d'ecriture. Pour l'instant je suis
seul a utiliser cette base car elle est toujours en cours de developpement.
Par contre si je modifie mes données dans sql, la, il n'y a pas de probleme.
Je ne trouve pas de solution a ce probleme extraiement genant. Merci d'avance a tous le monde
Bonjour, tu as pensé aux droits d'acces de SQL server ??? le plus simple , dans mon cas , dans access utilisé l'authentification courante et dans SQLserver ajouter les users NT sur ta base / table et cliquez les petites case qui vont bien !
DJ
didier TEST
"bambi" a écrit dans le message de news:
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec une appli access ou n'importe quoi d'autre. la BD en elle meme c'est Sql server pas access. Ok ? Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer patte blanche pour allez voir les datas . Dans la liaison de tes tables ou tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes tables dans les propriétées/ authoriastion tu vas ajouter les nom NT d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca marche !
DJ
"bambi" <bambi@discussions.microsoft.com> a écrit dans le message de
news:8870C32A-0B44-4A6A-BD9B-8C1339B298B8@microsoft.com...
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows.
L'utilisateur que j'utilise est considere comme dbo dans sql.
Je ne pense pas que ca vient de la, je developpe ma base access
directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant
dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont
faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec
une appli access ou n'importe quoi d'autre.
la BD en elle meme c'est Sql server pas access. Ok ?
Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer
patte blanche pour allez voir les datas . Dans la liaison de tes tables ou
tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la
connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes
tables dans les propriétées/ authoriastion tu vas ajouter les nom NT
d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca
marche !
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec une appli access ou n'importe quoi d'autre. la BD en elle meme c'est Sql server pas access. Ok ? Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer patte blanche pour allez voir les datas . Dans la liaison de tes tables ou tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes tables dans les propriétées/ authoriastion tu vas ajouter les nom NT d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca marche !
DJ
bambi
Je m'authentifie sur sql par mon compte windows. Access se sert d'un lien ODBC pour communiquer avec SQL. Sur ce lien ODBC j'utilise un utilisateur ODBC que j'ai creer et qui fait partie de tous les rôles et qui a acces a la base sql. J'ai deja 5 tables qui marchent bien et une qui a le probleme. Au depart sur la premiere table que j'avais creer, j'ai creer des formulaires baser sur cette table. Quand je modifiais une donnee par le biais d'un formulaire il me sortait le message de conflit d'ecriture. De la en cherchant un peu j'ai cru que sa venait du mode de recordset. J'etais en dynamique. Je l'ai passer en mise a jour globale et la sa c'est mis a marcher. depuis sur toutes les autres tables et formulaires j'ai fais pareil et ca a marcher. Sauf sur la derniere que je viens de creer. Que se soit en n'importe quel mode de recordset. C'est de la ou je me suis dis que ca ne venait pas de la. J'ai repasser sur les anciens formulaires les recordset en dynamique et maintenant ca marche aussi. Mais pourquoi ca ne amrche pas sur les derniers, ca je n'arrive pas a le comprendre. Au niveau securite, je suis sure que c'est bon.
"bambi" a écrit dans le message de news:
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec une appli access ou n'importe quoi d'autre. la BD en elle meme c'est Sql server pas access. Ok ? Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer patte blanche pour allez voir les datas . Dans la liaison de tes tables ou tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes tables dans les propriétées/ authoriastion tu vas ajouter les nom NT d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca marche !
DJ
Je m'authentifie sur sql par mon compte windows. Access se sert d'un lien
ODBC pour communiquer avec SQL. Sur ce lien ODBC j'utilise un utilisateur
ODBC que j'ai creer et qui fait partie de tous les rôles et qui a acces a la
base sql.
J'ai deja 5 tables qui marchent bien et une qui a le probleme.
Au depart sur la premiere table que j'avais creer, j'ai creer des
formulaires baser sur cette table. Quand je modifiais une donnee par le biais
d'un formulaire il me sortait le message de conflit d'ecriture.
De la en cherchant un peu j'ai cru que sa venait du mode de recordset.
J'etais en dynamique. Je l'ai passer en mise a jour globale et la sa c'est
mis a marcher. depuis sur toutes les autres tables et formulaires j'ai fais
pareil et ca a marcher. Sauf sur la derniere que je viens de creer. Que se
soit en n'importe quel mode de recordset. C'est de la ou je me suis dis que
ca ne venait pas de la. J'ai repasser sur les anciens formulaires les
recordset en dynamique et maintenant ca marche aussi.
Mais pourquoi ca ne amrche pas sur les derniers, ca je n'arrive pas a le
comprendre. Au niveau securite, je suis sure que c'est bon.
"bambi" <bambi@discussions.microsoft.com> a écrit dans le message de
news:8870C32A-0B44-4A6A-BD9B-8C1339B298B8@microsoft.com...
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows.
L'utilisateur que j'utilise est considere comme dbo dans sql.
Je ne pense pas que ca vient de la, je developpe ma base access
directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant
dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont
faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec
une appli access ou n'importe quoi d'autre.
la BD en elle meme c'est Sql server pas access. Ok ?
Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer
patte blanche pour allez voir les datas . Dans la liaison de tes tables ou
tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la
connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes
tables dans les propriétées/ authoriastion tu vas ajouter les nom NT
d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca
marche !
Je m'authentifie sur sql par mon compte windows. Access se sert d'un lien ODBC pour communiquer avec SQL. Sur ce lien ODBC j'utilise un utilisateur ODBC que j'ai creer et qui fait partie de tous les rôles et qui a acces a la base sql. J'ai deja 5 tables qui marchent bien et une qui a le probleme. Au depart sur la premiere table que j'avais creer, j'ai creer des formulaires baser sur cette table. Quand je modifiais une donnee par le biais d'un formulaire il me sortait le message de conflit d'ecriture. De la en cherchant un peu j'ai cru que sa venait du mode de recordset. J'etais en dynamique. Je l'ai passer en mise a jour globale et la sa c'est mis a marcher. depuis sur toutes les autres tables et formulaires j'ai fais pareil et ca a marcher. Sauf sur la derniere que je viens de creer. Que se soit en n'importe quel mode de recordset. C'est de la ou je me suis dis que ca ne venait pas de la. J'ai repasser sur les anciens formulaires les recordset en dynamique et maintenant ca marche aussi. Mais pourquoi ca ne amrche pas sur les derniers, ca je n'arrive pas a le comprendre. Au niveau securite, je suis sure que c'est bon.
"bambi" a écrit dans le message de news:
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec une appli access ou n'importe quoi d'autre. la BD en elle meme c'est Sql server pas access. Ok ? Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer patte blanche pour allez voir les datas . Dans la liaison de tes tables ou tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes tables dans les propriétées/ authoriastion tu vas ajouter les nom NT d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca marche !
DJ
bambi
Merci pour ton aide. Je viens de trouver !! En fait j'ai des champs au format bit sous sql. Comme valeur dans le champs dans sql il me marque null. Si on regarde dans access, il y a des 0 a la place. Si dans sql je change le null par de 0 aussi, et bien la sa marche dans access. J'ai l'impression que le passage de sql a access pour les champs bit est a revoir!! Pour info, j'ai deja essayer en disant a sql que la valeur par defaut du champ bit est 0 mais il me met toujours Null et ca ne marche pas non plus.
Je m'authentifie sur sql par mon compte windows. Access se sert d'un lien ODBC pour communiquer avec SQL. Sur ce lien ODBC j'utilise un utilisateur ODBC que j'ai creer et qui fait partie de tous les rôles et qui a acces a la base sql. J'ai deja 5 tables qui marchent bien et une qui a le probleme. Au depart sur la premiere table que j'avais creer, j'ai creer des formulaires baser sur cette table. Quand je modifiais une donnee par le biais d'un formulaire il me sortait le message de conflit d'ecriture. De la en cherchant un peu j'ai cru que sa venait du mode de recordset. J'etais en dynamique. Je l'ai passer en mise a jour globale et la sa c'est mis a marcher. depuis sur toutes les autres tables et formulaires j'ai fais pareil et ca a marcher. Sauf sur la derniere que je viens de creer. Que se soit en n'importe quel mode de recordset. C'est de la ou je me suis dis que ca ne venait pas de la. J'ai repasser sur les anciens formulaires les recordset en dynamique et maintenant ca marche aussi. Mais pourquoi ca ne amrche pas sur les derniers, ca je n'arrive pas a le comprendre. Au niveau securite, je suis sure que c'est bon.
"bambi" a écrit dans le message de news:
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec une appli access ou n'importe quoi d'autre. la BD en elle meme c'est Sql server pas access. Ok ? Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer patte blanche pour allez voir les datas . Dans la liaison de tes tables ou tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes tables dans les propriétées/ authoriastion tu vas ajouter les nom NT d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca marche !
DJ
Merci pour ton aide.
Je viens de trouver !!
En fait j'ai des champs au format bit sous sql. Comme valeur dans le champs
dans sql il me marque null. Si on regarde dans access, il y a des 0 a la
place.
Si dans sql je change le null par de 0 aussi, et bien la sa marche dans
access. J'ai l'impression que le passage de sql a access pour les champs bit
est a revoir!!
Pour info, j'ai deja essayer en disant a sql que la valeur par defaut du
champ bit est 0 mais il me met toujours Null et ca ne marche pas non plus.
Je m'authentifie sur sql par mon compte windows. Access se sert d'un lien
ODBC pour communiquer avec SQL. Sur ce lien ODBC j'utilise un utilisateur
ODBC que j'ai creer et qui fait partie de tous les rôles et qui a acces a la
base sql.
J'ai deja 5 tables qui marchent bien et une qui a le probleme.
Au depart sur la premiere table que j'avais creer, j'ai creer des
formulaires baser sur cette table. Quand je modifiais une donnee par le biais
d'un formulaire il me sortait le message de conflit d'ecriture.
De la en cherchant un peu j'ai cru que sa venait du mode de recordset.
J'etais en dynamique. Je l'ai passer en mise a jour globale et la sa c'est
mis a marcher. depuis sur toutes les autres tables et formulaires j'ai fais
pareil et ca a marcher. Sauf sur la derniere que je viens de creer. Que se
soit en n'importe quel mode de recordset. C'est de la ou je me suis dis que
ca ne venait pas de la. J'ai repasser sur les anciens formulaires les
recordset en dynamique et maintenant ca marche aussi.
Mais pourquoi ca ne amrche pas sur les derniers, ca je n'arrive pas a le
comprendre. Au niveau securite, je suis sure que c'est bon.
"bambi" <bambi@discussions.microsoft.com> a écrit dans le message de
news:8870C32A-0B44-4A6A-BD9B-8C1339B298B8@microsoft.com...
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows.
L'utilisateur que j'utilise est considere comme dbo dans sql.
Je ne pense pas que ca vient de la, je developpe ma base access
directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant
dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont
faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec
une appli access ou n'importe quoi d'autre.
la BD en elle meme c'est Sql server pas access. Ok ?
Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer
patte blanche pour allez voir les datas . Dans la liaison de tes tables ou
tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la
connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes
tables dans les propriétées/ authoriastion tu vas ajouter les nom NT
d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca
marche !
Merci pour ton aide. Je viens de trouver !! En fait j'ai des champs au format bit sous sql. Comme valeur dans le champs dans sql il me marque null. Si on regarde dans access, il y a des 0 a la place. Si dans sql je change le null par de 0 aussi, et bien la sa marche dans access. J'ai l'impression que le passage de sql a access pour les champs bit est a revoir!! Pour info, j'ai deja essayer en disant a sql que la valeur par defaut du champ bit est 0 mais il me met toujours Null et ca ne marche pas non plus.
Je m'authentifie sur sql par mon compte windows. Access se sert d'un lien ODBC pour communiquer avec SQL. Sur ce lien ODBC j'utilise un utilisateur ODBC que j'ai creer et qui fait partie de tous les rôles et qui a acces a la base sql. J'ai deja 5 tables qui marchent bien et une qui a le probleme. Au depart sur la premiere table que j'avais creer, j'ai creer des formulaires baser sur cette table. Quand je modifiais une donnee par le biais d'un formulaire il me sortait le message de conflit d'ecriture. De la en cherchant un peu j'ai cru que sa venait du mode de recordset. J'etais en dynamique. Je l'ai passer en mise a jour globale et la sa c'est mis a marcher. depuis sur toutes les autres tables et formulaires j'ai fais pareil et ca a marcher. Sauf sur la derniere que je viens de creer. Que se soit en n'importe quel mode de recordset. C'est de la ou je me suis dis que ca ne venait pas de la. J'ai repasser sur les anciens formulaires les recordset en dynamique et maintenant ca marche aussi. Mais pourquoi ca ne amrche pas sur les derniers, ca je n'arrive pas a le comprendre. Au niveau securite, je suis sure que c'est bon.
"bambi" a écrit dans le message de news:
Bonjour Didier,
Au niveau securite, je suis en mode d'authentification windows. L'utilisateur que j'utilise est considere comme dbo dans sql. Je ne pense pas que ca vient de la, je developpe ma base access directement
sur mon serveur sql et dans SQL je peux modifiers les données en rentrant dans les tables.
BEN oui visiblement c'est bien ce que je dis :-)))
1- c'est pas une base Acceess dans ton Sql ce sont des tables qui sont faites directement dans SQLserver que tu vas attaquer de l'exterrieur avec une appli access ou n'importe quoi d'autre. la BD en elle meme c'est Sql server pas access. Ok ? Le proprio est dbo et dans SQLServer pas de probleme
2- maitenant dans ton Frontal Access, tu es HORS SQLserver donc faut montrer patte blanche pour allez voir les datas . Dans la liaison de tes tables ou tu rentres le user/mdp qui va bien ou tu coches la case "utiliser la connexion approuvée" (pas de code a rentrer) et dans SQL serveur sur tes tables dans les propriétées/ authoriastion tu vas ajouter les nom NT d'utilisateur et cocher les cases de droits qui vont bien. et HOP ! ca marche !
DJ
didier TEST
"bambi" a écrit dans le message de news:
Merci pour ton aide. Je viens de trouver !! En fait j'ai des champs au format bit sous sql. Comme valeur dans le champs
dans sql il me marque null. Si on regarde dans access, il y a des 0 a la place. Si dans sql je change le null par de 0 aussi, et bien la sa marche dans access. J'ai l'impression que le passage de sql a access pour les champs bit
est a revoir!! Pour info, j'ai deja essayer en disant a sql que la valeur par defaut du champ bit est 0 mais il me met toujours Null et ca ne marche pas non plus.
1- Ah ben oui avec ta description plus complete je vois mieux et effectivemet ca devait venir d'ailleurs
2-Tant mieux car du coup je voyais pas trop ... :-)) je suis pas au top sur sqlserver... mais j'ai effectivment remarqué qu'il y a certains type de chmaps qui peuvent donner des resultat bizarre sous acces ...
bonne continuation. DJ
"bambi" <bambi@discussions.microsoft.com> a écrit dans le message de
news:0E111E58-6937-4D19-B48D-41CB1845880C@microsoft.com...
Merci pour ton aide.
Je viens de trouver !!
En fait j'ai des champs au format bit sous sql. Comme valeur dans le
champs
dans sql il me marque null. Si on regarde dans access, il y a des 0 a la
place.
Si dans sql je change le null par de 0 aussi, et bien la sa marche dans
access. J'ai l'impression que le passage de sql a access pour les champs
bit
est a revoir!!
Pour info, j'ai deja essayer en disant a sql que la valeur par defaut du
champ bit est 0 mais il me met toujours Null et ca ne marche pas non plus.
1- Ah ben oui avec ta description plus complete je vois mieux et
effectivemet ca devait venir d'ailleurs
2-Tant mieux car du coup je voyais pas trop ... :-)) je suis pas au top sur
sqlserver... mais j'ai effectivment remarqué qu'il y a certains type de
chmaps qui peuvent donner des resultat bizarre sous acces ...
Merci pour ton aide. Je viens de trouver !! En fait j'ai des champs au format bit sous sql. Comme valeur dans le champs
dans sql il me marque null. Si on regarde dans access, il y a des 0 a la place. Si dans sql je change le null par de 0 aussi, et bien la sa marche dans access. J'ai l'impression que le passage de sql a access pour les champs bit
est a revoir!! Pour info, j'ai deja essayer en disant a sql que la valeur par defaut du champ bit est 0 mais il me met toujours Null et ca ne marche pas non plus.
1- Ah ben oui avec ta description plus complete je vois mieux et effectivemet ca devait venir d'ailleurs
2-Tant mieux car du coup je voyais pas trop ... :-)) je suis pas au top sur sqlserver... mais j'ai effectivment remarqué qu'il y a certains type de chmaps qui peuvent donner des resultat bizarre sous acces ...
