Cadena que actúa de forma anómala en un bucle For Each en código VBA en MSAccess

votos
-2

De acuerdo, comencé con una pregunta y realicé muchos cambios en el código en función de las sugerencias de este sitio y de otros, así que pensé que debería crear una nueva pregunta.

Aunque mi código es más corto y más eficiente, el mismo problema persiste; Estoy usando una cadena llamada strSQL que contiene la instrucción INSERT IGNORE que quiero ejecutar. Tengo un POR CADA bucle que pasa por cada control en mi formulario MSAcess (asegura que son un cuadro de texto, una lista desplegable o una casilla de verificación) y determina si el campo ha sido cambiado. Si lo tiene, genera una cadena de consulta para registrar el cambio y lo almacena en strSQL.

El problema es que la misma consulta se ejecuta una y otra vez. He agregado una declaración DEBUG.PRINT antes y después de la línea que ejecuta la cadena de consulta y el depurador muestra que la cadena ha CAMBIADO! Sí, lo leíste bien, esto parece ser imposible, pero he tomado capturas de pantalla.

Primero mi código:

Private Sub Form_BeforeUpdate(Cancel As Integer)
    Dim C As Control
    For Each C In Controls
        Select Case C.ControlType
            Case acTextBox, acComboBox, acCheckBox
                Dim strOriginalValue, strCurrentValue, strSQL As String

                strOriginalValue = IIf(IsNull(C.OldValue), , IIf(C.OldValue = vbTrue Or C.OldValue = vbFalse, IIf(C.OldValue = vbTrue, Yes, No), C.OldValue))
                strCurrentValue = IIf(IsNull(C.Value), , IIf(C.Value = vbTrue Or C.Value = vbFalse, IIf(C.Value = vbTrue, Yes, No), C.Value))

                If strOriginalValue <> strCurrentValue Then
                    strSQL = INSERT IGNORE  INTO fringefestival_changes (change_time,change_admin,action_taken,user_affected,year_affected,field_affected,type_affected,old_value,new_value) VALUES (NOW(),' & ThisUserName() & ','Edit', & [id] & ,0,' & C.ControlSource & ','Administrator',' & Replace(strOriginalValue, ', ) & ',' & Replace(strCurrentValue, ', ) & ')
                    Debug.Print Before:  & strSQL
                    CurrentDb.Execute strSQL, dbFailOnError
                    Debug.Print After:  & strSQL
                End If
        End Select
    Next
End Sub

Aquí están los resultados del depurador:

Before: INSERT IGNORE  INTO fringefestival_changes (change_time,change_admin,action_taken,user_affected,year_affected,field_affected,type_affected,old_value,new_value) VALUES (NOW(),'ajohnson','Edit',3,0,'indoor_performers_tab','Administrator','No','Yes')
After: INSERT IGNORE  INTO fringefestival_changes (change_time,change_admin,action_taken,user_affected,year_affected,field_affected,type_affected,old_value,new_value) VALUES (NOW(),'ajohnson','Edit',3,0,'indoor_performers_tab','Administrator','No','Yes')
Before: INSERT IGNORE  INTO fringefestival_changes (change_time,change_admin,action_taken,user_affected,year_affected,field_affected,type_affected,old_value,new_value) VALUES (NOW(),'ajohnson','Edit',3,0,'volunteers_tab','Administrator','No','Yes')
After: INSERT IGNORE  INTO fringefestival_changes (change_time,change_admin,action_taken,user_affected,year_affected,field_affected,type_affected,old_value,new_value) VALUES (NOW(),'ajohnson','Edit',3,0,'volunteers_tab','Administrator','No','Yes')

En segundo lugar mis capturas de pantalla ... primero el depurador: 1 y 2 y en segundo lugar los resultados: aquí - tenga en cuenta que el depurador es demasiado ancho, así que tomé dos capturas de pantalla y los resultados tienen una fila coloreada ya que no tiene nada que ver con este problema .

Tenga en cuenta que la única columna que debería ser diferente en el ejemplo que di debería ser la columna field_affected.

Estoy en una pérdida completa, no tengo idea de por qué arrojaría la cadena correcta al depurador y ejecutaría algo más.

EDITAR: Antes de usar CurrentDb.Execute, estaba usando DoCmd.RunSQL, pero esto requería que desactivara y luego volviera a habilitar las advertencias. Como el resultado fue el mismo para ambos (el mismo error) utilicé la solución de una línea en lugar de la solución de tres líneas.

ACTUALIZACIÓN: Shoutout a shahkalpesh por ayudarme a darme cuenta de que los datos se están insertando correctamente y puedo verlos en el estudio de administración de SQL Server, pero MS Access sigue mostrándolos de forma incorrecta ... la pregunta es ¿por qué?

EDICIÓN FINAL: Corregida al agregar una columna de enteros de identidad / autoincremento a la tabla, sospecho que la falta de valores de campo diferentes confundía a MSAccess (aunque realmente no tiene ninguna razón) - la moral aquí es M $ es estúpida

Publicado el 28/12/2008 a las 22:26
fuente por usuario
En otros idiomas...                            


7 respuestas

votos
1

¿Está el formulario en cuestión vinculado a una fuente de datos? Esta es la forma más común de utilizar Access, y si lo fuera probablemente no necesitaría actualizarse a través de SQL.

Form_BeforeUpdate () se usa generalmente cuando un formulario está vinculado a un origen de datos. Normalmente, no utilizarías este evento para determinar si los valores de los controles han cambiado y si es necesario escribir nuevamente en el DB ...

Respondida el 28/12/2008 a las 23:12
fuente por usuario

votos
0

¿Ejecutas esas consultas contra currentdb (que supongo que es el acceso-db) pero de hecho están utilizando una base de datos del servidor SQL donde quieres que ocurran los cambios?

¿Están esas tablas en el servidor sql vinculadas a tablas en access-db o qué método estás usando?

Respondida el 28/12/2008 a las 23:20
fuente por usuario

votos
0

¿Has revisado la tabla en busca de desencadenadores rotos? Es una posibilidad remota, pero algunos problemas muy extraños han sido causados ​​por disparadores malos / rotos antes, y son difíciles de entender antes de que notes el disparador ...

Respondida el 28/12/2008 a las 23:32
fuente por usuario

votos
1

Si puede ir a la tabla específica de SQL Server (utilizando el Analizador de consultas o Enterprise Mgr) y ver si funciona como espera. Dudo que la tabla vinculada en VBA pueda mostrarle una imagen incorrecta.

Editar: si tiene el Analizador de SQL, vea qué se está ejecutando allí para confirmar su duda de que se ejecute la misma consulta.

Respondida el 29/12/2008 a las 01:13
fuente por usuario

votos
-1

Ah, también estás usando SQL Server. He tenido mucha suerte con el uso de activadores para auditar los cambios de datos detrás de Access. Hay un par de peculiaridades, pero vincular las tablas a través de ODBC mediante autenticación de confianza lo hace muy fácil.

OK, entonces no puedes o no quieres usar disparadores. Cuando SQL de entrada con acceso, usualmente uso objetos ADO en mi código VBA para este tipo de cosas. Las tablas vinculadas con ODBC son excelentes para formularios enlazados, pero nada supera a ADO para ir directamente al servidor SQL.

¿Desea más información sobre cómo vincular las tablas con autenticación confiable o ayuda con el uso de ADO para hacer el trabajo con SQL Server?

Respondida el 29/12/2008 a las 01:38
fuente por usuario

votos
0

Se corrigió añadiendo una columna de clave primaria entera autoincrementada a la tabla de cambios.

Acceso tonto ...

Respondida el 29/12/2008 a las 01:51
fuente por usuario

votos
-1

Debo decir que la discusión sobre esta pregunta me vuelve loco. Con las tablas vinculadas de ODBC, comienza con formularios enlazados. Simplemente no hay razón para usar conexiones agrupadas. Si es hostil a la implementación de Access sobre cómo hacer esto, DEJE DE USAR ACCESO.

Respondida el 02/01/2009 a las 01:51
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more