Créer un formulaire non lié dans Acess 2007

Question

J'ai une application d'accès qui a un formulaire qui permet à l'utilisateur d'entrer des notes de cas. Le champ principal de ce formulaire est lié à un champ SQL Server varchar (MAX) dans la table source. Depuis que les utilisateurs sont passés à Access 2007, leur programme se bloque lorsqu'ils sont sur le formulaire de notes de cas. Comme une solution possible à ce problème, je voudrais essayer de délier ce formulaire et de le reconstruire comme une forme non liée.

Ce formulaire doit être en mesure d'ajouter et de dossiers de mise à jour dans ma base de données SQL Server. Il doit également être capable de naviguer entre les enregistrements. Je suppose que je ne sais pas par où commencer. Toutes les suggestions/extraits de code sont appréciés.

Answer 1

Comme point de départ, essayez Google sur "forme non liée dans Access". Ne soyez pas distrait par PacMan! ;)

Quoi qu'il en soit, l'idée de base d'une forme non liée est de charger les données dans les contrôles non liés d'un jeu d'enregistrements, puis l'enregistrer en arrière quand les modifications sont effectuées. Cela signifie que vous avez besoin de ces choses:

1. contrôle pour sélectionner l'enregistrement nécessaire, une sorte de fonctionnalité de recherche.

2. Code

   pour ouvrir le jeu d'enregistrements et écrire les données des champs dans les commandes correspondantes sur le formulaire.

3. contrôles pour sauvegarder l'enregistrement de retour à la base de données, qui utilisera une mise à jour de SQL pour écrire les valeurs dans les contrôles non liés à la base de données de retour. Je préfère ne pas mettre à jour les champs qui n'ont pas changé (parce que je fais beaucoup d'applications Jet répliquées, et plusieurs mises à jour peuvent entraîner des conflits de réplication inutiles). Vous pouvez comparer les données des contrôles non liés aux données du jeu d'enregistrements d'origine (si vous l'ouvrez en tant que jeu d'enregistrements de type instantané, il ne reflétera aucune mise à jour depuis son ouverture) et écrire votre SQL UPDATE uniquement pour les champs les valeurs ne correspondent pas. Vous devrez tenir compte des Nuls.

La pratique courante consiste à nommer les contrôles exactement les mêmes que les champs qu'ils correspondent à afin que vous puissiez boucle les champs de la recordset collection et charger les données dans les contrôles:

For Each fld In rs.Fields 
    Me.Controls(fld.Name) = fld.Value 
    Next fld 

Vous pouvez faire De même, pour enregistrer les données et vérifier les valeurs de contrôle par rapport aux valeurs du jeu d'enregistrements d'origine. Je ne sais pas si cela fonctionne avec les champs SQL Server VarChar() ou non, mais vous pouvez également essayer ce que j'appelle un formulaire "semi-lié", où vous chargez le jeu d'enregistrements avec la propriété RecordSource du formulaire, mais don Ne liez pas les champs aux contrôles. Ainsi, le formulaire est lié, mais les contrôles ne le sont pas. Je le fais très souvent avec une forme entièrement liée où je rends les champs de mémo non liés (pour éviter le risque de corruption de pointeur de champ de mémo dans le dos de Jet/ACE). Dans ce cas, avec un jeu d'enregistrements de forme liée et une zone de texte non liée pour l'édition, vous feriez ceci:

1. dans le cas OnCurrent la forme, chargez le champ non consolidé des données (s) dans la zone de texte non liée correspondant (es). Dans les événements AfterUpdate du (des) contrôle (s) non lié (s), inscrivez les données dans la (les) zone (s) de texte non liée (s) à la source d'enregistrements.

Ces deux étapes chercheraient essentiellement quelque chose comme ceci:

Private Sub Form_Current() 
    Me!txtMemo = Me!Memo 
    End Sub 

    Private Sub txtMemo_AfterUpdate() 
    Me!Memo = Me!txtMemo 
    Me.Dirty = False 
    End Sub 

Avec une extrémité arrière Jet/ACE, vous voulez sauvegarder l'enregistrement immédiatement après que vous écrivez la valeur du champ mémo, car sinon vous n'avez pas évité le danger de corrompre le pointeur de champ Mémo. Avec un back-end SQL Server, vous pouvez ou ne pas avoir besoin de faire cela, car les problèmes sont complètement différents. L'enregistrement libère le verrou en écriture, mais vous n'avez pas besoin de l'éviter.

En outre, je suppose que les données VarChar() peuvent être lues à partir du Recordsource sous-jacent du formulaire et écrites dans la zone de texte. Vous devrez voir si cela fonctionne.