Timeout ?...
Jean-Paul Argudo/ = 25 Mai, 2005 - 17:08
Bonjour,
Ça ressemble à un timeout... Qu'avez-vous en paramètres du driver ODBC PostgreSQL ?... N'y aurait-il pas là dedans, par hasard, un timeout, un connexion timeout ou ce genre de chose ?
Au lieu de fermer/rouvrir Access, n'avez-vous pas le moyen à l'intérieur d'Access de provoquer un rafraîchissement des données ?
--
Jean-Paul ARGUDO
www.PostgreSQLFr.org
[ Vous devez
vous connecter pour poster des commentaires ]
Histoire de version de drivers ODBC ?
Mirage/ = 27 Mai, 2005 - 14:25
Bonjour,
j'avais également l'apparition de "#supprimé" dans tous les champs de mes tables avec la version 8.00.00.04 du drivers ODBC windows, le problème a été contourné en utilisant la version 7.02.00.05 (beta).
Voici donc peut être une piste.
Pierre-Emmanuel
[ Vous devez
vous connecter pour poster des commentaires ]
Ms-Access et les identificateurs d'enregistrements
jef-Hl/ = 1 Juin, 2005 - 15:41
Bonjour,
J'ai eu le meme problème , mais seulement avec des tables dont la primary key est de type texte !
Je contourne le problème en modifiant 2 parametres du driver ODBC Postgresql 8.00.01.01.
Dans l'onglet Datasource /page1 : je dé-coche [recognize Unique Indexes] et dans /page2 : je coche l'option [show column] de l'OID.
Depuis access , j'efface les attaches des tables qui posent problème
puis je les attache de nouveau en choisissant comme identificateur d'enregistrement unique l'OID.
En ouvrant la table avec access, le Champ OID apparait, mais je n'ai plus de "#supprimé" et les insertions, modifications, suppressions fonctionnent sans aucune autre modification.
JEF.
[ Vous devez
vous connecter pour poster des commentaires ]
Problème avec MS-Access comme Front End pour Postgresql
lucrol/ = 10 Juin, 2005 - 19:36
Bonjour,
"#Deleted" Errors with linked ODBC tables est un problème MS-ACCESS !
Il fait l'objet de l'article Q128809 de la base de connaissances MSDN.
La cause est que pour les tables liées via ODBC (quelque soit le gestionnaire de données) Access traite mal les tables dont les clefs primaires sont de type Texte (Char, Varchar, Text...).
La solution est de supprimer ces clefs primaires (REMOVE CONSTRAINT ...) et de créer des clefs primaires de type integer (autoincrémentées de préférence).
Par exemple :
-- Ajouter un champ de type Access "NuméroAuto"
ALTER TABLE categ
ADD pk_categ bigserial ;
COMMENT ON COLUMN categ.pk_categ IS 'PK (Numéro Auto)' ;
-- Effacer l'ancienne clef primaire
ALTER TABLE categ
DROP CONSTRAINT categ_pk ;
-- Recréer une clef primaire numérique
ALTER TABLE categ
ADD CONSTRAINT categ_pk PRIMARY KEY(pk_categ) ;
COMMENT ON CONSTRAINT categ_pk ON categ IS 'Clef Primaire' ;
J'ai rencontré un autre type de problème avec Access et les tables liées : l'exemple ci-dessus ne fonctionne pas (sur mon serveur postgreSQL 8.0.3 sous Windows 2003 server) si on utilise le type bigserial au lieu de serial comme ci-dessus !?
Un autre conseil : utiliser des noms de table et de champ pas trop long dans la base PostgreSQL, sinon gare aux soucis !...
Il reste cependant possible d'utiliser des noms de table longs pour les liens Access sans inconvénient.
Exemple : "Adresse Postale Professionelle" liée à public.adrpostprof
Il est évident que dans une base postgresql il est recommandé de mettre les noms en minuscule et d'éviuter toute forme d'accentués et de caractères spéciaux !
Que la force (de PostgreSQL) soit avec vous...
[ Vous devez
vous connecter pour poster des commentaires ]