2009-07-28 10 views
1

Je travaille sur un programme qui a besoin d'éditer certains objets dans une base de données Access. Il exécute également un sous-programme (longue histoire) qui tente d'accéder à la base de données JET sous-jacente tandis qu'Access l'a toujours ouvert via ODBC.Comment passer d'une base de données Access au mode partagé et au mode exclusif?

Le problème est que dès que je commence à éditer des objets de formulaire en utilisant VBA - par exemple, en utilisant Application.LoadFromText - Access change la base de données en mode exclusif. Le mode exclusif en lui-même est parfait, et je sais pourquoi il en a besoin. Mais j'ai besoin de pouvoir revenir en mode "partagé" par la suite pour pouvoir exécuter mon sous-programme.

J'ai remarqué que si vous utilisez l'interface utilisateur pour ouvrir un formulaire en mode Conception, Access bascule la base de données vers Exclusive. (Vous pouvez le confirmer en essayant de l'ouvrir à partir d'un autre ordinateur.) Mais lorsque vous fermez le concepteur de formulaires, Access le ramène immédiatement en mode partagé, ce que j'espère.

Y a-t-il un moyen de le faire basculer moi-même en utilisant les appels VBA/COM?

Je sais que je peux appeler Application.CloseCurrentDatabase() suivi par OpenCurrentDatabase(), mais cela ferme toutes les fenêtres et perturbe l'interface utilisateur, donc ce n'est pas idéal.

+0

J'ai trouvé une solution de contournement: ouvrez n'importe quel formulaire et fermez-le. Cela semble amener Access à reconsidérer si elle a besoin de la base de données pour rester en mode exclusif ou non. C'est assez grossier, cependant. – apenwarr

+0

Votre question est source de confusion, car Access ne peut pas se connecter à ses propres fichiers de données (Jet/ACE) en utilisant ODBC. –

+0

A droite, mon sous-programme est en réalité écrit en C++. Tant qu'Access n'a pas le fichier .mdb ouvert, ou qu'il l'a ouvert en mode partagé, le programme C++ n'a aucun problème à le manipuler via ODBC. (Et c'est environ 10 fois plus rapide que DAO ou ADO, ou nous emprunterions simplement la connexion DAO à partir de la base de données Access ouverte.) – apenwarr

Répondre

5

Divise la base de données en une partie frontale distincte avec les formulaires/modules/etc. et back-end avec les tables une option? De cette façon, si l'interface est verrouillée, l'arrière-plan est toujours accessible. Access a un assistant de fractionnement de base de données pour cela.

+0

C'est une option - et certaines bases de données où je fais sont divisées de cette façon - mais c'est non -idéal. Je n'ai pas besoin de faire des opérations * alors que * c'est verrouillé, je dois juste pouvoir verrouiller et déverrouiller à la demande. – apenwarr

+0

Le fractionnement est la seule réponse sensée. –

+0

Si c'est vrai, alors c'est triste. Les bases de données en question sont petites et simples, et c'est une honte de les forcer à se séparer juste à cause d'un problème de verrouillage trivial. – apenwarr

0

Vous pourriez essayer .UserControl et .Visible. Je les utilise pour transférer le contrôle dans des processus automatisés. Je ne sais pas s'ils vont vous aider, mais vous pouvez voter contre si ce n'est pas le cas.

+0

Je ne suis pas sûr que cela fera quelque chose d'utile. La base de données est ouverte exclusivement; Cela n'empêche pas l'application VBA de le contrôler. – apenwarr

Questions connexes