Cambiar recordsource de subform SQL Server
Impreso de: Foro de Access y VBA
Categoría: Access y VBA
Nombre del foro: Access y Otros sistemas
Descripción del foro: Proyectos ADP & Sql Server, Mysql& Access, MSDE
URL: http://www.mvp-access.com/foro/forum_posts.asp?TID=86060
Fecha de impresión: 26/Marzo/2026 a las 15:29
Tema: Cambiar recordsource de subform SQL Server
Publicado por: Baraka
Asunto: Cambiar recordsource de subform SQL Server
Fecha de publicación: 15/Junio/2021 a las 21:35
|
Tengo un front-end en Access 2019 y back-end en SQL Server. Necesito modificar el origen de datos de un subformulario en base a un combobox del formulario primcipal. El origen siempre es una tabla con los mismos campos. He probado diferentes opciones pero todas tienen inconvenientes. 1.- Unirlas en una única tabla es inviable, cada una tiene un tamaño considerable y son miles. 2.- Por seguridad elimino la vinculacion de las tablas al cerrar y revinculo al abrir el front-end, por lo que vincular todas las tablas ralentiza demasiado la aplicacion. 3.- Vincular "al vuelo" cada tabla funciona razonablemente bien pero, si se cierra el programa por error, el controlsource mantiene la referencia que ya no existe (al reabrir la tabla ya no esta vinculada) y el subformulario no se carga, dando un error. El front-end está en .accde por lo no puedo cambiar en controlsource en modo diseño. 4. Vincular todas las tablas siempre con el mismo nombre de tabla en local evita el error anterior pero, si realizo múltiples cambios, borrados, etc. , al tratar de actualizar el recordsource se produce el siguiente error "no se puede actualizar en medio de una transacción". Deduzco que access realiza una transaccion internamente con todos los cambios que no puedo controlar, ni forzando el refresco o actualización de los datos. El resto de la aplicacion funciona bien tanto con tablas o consultas vinculadas desde el principio o "al vuelo" pero esta es la primera vez que me encuentro con la necesidad de cambiar el origen de un subformulario "al vuelo" sobre diferentes tablas y ya no se me ocurren más alternativas. ¿Alguien tiene un escenario similar que le funcione o se le ocurre otra alternativa? Gracias por cualquier sugerencia. |
Respuestas:
Publicado por: Mihura
Fecha de publicación: 15/Junio/2021 a las 21:53
|
Prueba a usar tablas sin vincular. Asignas recordset al subformulario por código y puede que lo tengas http://www.mvp-access.com/foro/formulario-con-tabla-sqlserver-sin-vincular_topic85987.html ------------- Jesús Mansilla Castells. Saludos desde Móstoles. http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones http://www.tecsys.es" rel="nofollow - Tecsys.es |
Publicado por: Baraka
Fecha de publicación: 16/Junio/2021 a las 19:18
|
No se me había ocurrido esta posibilidad, por defecto siempre parto del uso de tablas vinculadas. Lo pruebo y te digo. Muchas gracias |
Publicado por: Baraka
Fecha de publicación: 17/Junio/2021 a las 21:38
|
Como era de esperar, al eliminar el RecordSource se elimina el problema del vínculo inexistente que generaba el error al cerrarse inesperadamente el programa, pero la verdad es que no termino de entender como funcionan la tablas sin vincular y si compensa. Estoy usándola en un subformulario en vista "hoja de datos" y he perdido la ordenación, búsqueda, etc. de las columnas, por lo que entiendo que hay que resolverlo programáticamente, pero tampoco veo con filtrar, ordenar, etc. sin necesidad de recargar el Recordset (veo que Docmd.Applyfilter y .Form.Filter ="", .Form.FilterOn = true tampoco funcionan) ¿Hay alguna alternativa? Por otro lado ¿hay alguna forma de usar tablas desconectadas sin necesidad de cargar en cada puesto el controlador OLE DB (MSOLEDBSQL)? Disculpa si son muchas preguntas, me salgo del tema original o no es el procedimiento correcto en este foro y gracias en cualquier caso. |
Publicado por: Mihura
Fecha de publicación: 17/Junio/2021 a las 22:14
Si, son muchas preguntas, pero voy a hacer como que no me he dado cuenta ...  No uso hoja de datos con lo que eso no te lo puedo responder, el tema de filtros, búsquedas, etc, lo tienes que hacer tú con VBA. Ten en cuenta que cuando tratas con tablas vinculadas (es decir tratadas como si fueran de Access), cuando lees la tabla clientes con el filtro 'andaluces' en realidad el equipo está recibiendo la tabla completa (todos los registros con todos los campos) y los filtros, ordenaciones, etc se hacen en el propio equipo. Cuando lo haces con las tablas sin vincular contra un BD de verdad (SQL - MySQL - ...) lo que recibe el equipo son 'solo' los registros de los clientes andaluces. ¿Merece la pena? ... en vez de tratar con 80.000 registros y 40 campos por registro, estás tratando con 8.000 registros y con sólo los campos seleccionados -no los 40-. Ya lo creo que merece la pena, en entornos profesionales con gran carga de trabajo. Otra cosa es en la aplicación de un sólo puesto con poca 'chicha'. Vamos, que hay que programar. Los drivers de SQL no hay que instalarlos en ningún equipo, ya vienen de serie con el güindous. Yo empleo la siguiente cadena de conexión: CnRemota.ConnectionString = "Provider=SQLOLEDB;Server=" & X1 & ";DataBase=" & X2 & ";UID=" & X3 & ";PWD=" & X4 CnRemota.Properties("Current Language") = "spanish" CnRemota.Open ¿Hay alternativa? .... el primer jefe que yo tuve entre otras muchas lecciones me dijo: - en informática SIEMPRE HAY OTRO CAMINO ------------- Jesús Mansilla Castells. Saludos desde Móstoles. http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones http://www.tecsys.es" rel="nofollow - Tecsys.es |
Publicado por: Baraka
Fecha de publicación: 18/Junio/2021 a las 16:45
|
Sin duda merece la pena limitar el tráfico, por eso me extrañaba que no se pudiera filtrar, ordenar, etc, el Recordset una vez lo tenemos asignado al RecordSource del formulario. (Al menos no con las herramientas habituales). Efectivamente toda mejora tiene un precio que suele pagarse en líneas de código.
Respecto a la cadena de conexión yo uso CnRemota = "Provider=MSOLEDBSQL; DataTypeCompatibility=80; Server=" & MiServidor & "; Database=" & MiBasedeDatos & "; UID=" & MiUsuario & "; PWD=" & MiClave & ";" (tengo SQL por defecto en español) Básicamente es igual salvo por el Provider: se supone que SQLOLEDB ya no se mantiene y no se recomienda para nuevos desarrollos (aunque me consta que funciona perfectamente, lo he usado hasta hace bien poco). OLE DB https://docs.microsoft.com/es-es/archive/blogs/sqlnativeclient/announcing-the-new-release-of-ole-db-driver-for-sql-server" rel="nofollow - dejó de estar en desuso y se relanzó en 2018 y se supone que es el que se actualizará con las características más recientes. Hasta dónde yo sé no viene por defecto con Windows y hay que instalarlo exprofeso en cada equipo. En mi caso he optado por que cuando el usuario se descarga una nueva versión del programa, código de instalación le instala también la última versión del controlador. http://docs.microsoft.com/es-es/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15" rel="nofollow - https://docs.microsoft.com/es-es/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15 Gracias de nuevo. |
Publicado por: Mihura
Fecha de publicación: 18/Junio/2021 a las 16:53
|
Yo me atengo a la máxima informática -Si funciona ¿pa'que lo arreglas? Cuando llegue el momento lo cambiaremos, de momento me ahorro el tener que irlo instalando, ... y de paso decirte que el SQL (y el MySQL) suele dar demasiadas sorpresas, ya que cada cliente tiene una versión a cuál más antigua -y todas con pequeñas tonterías que las hacen incompatibles entre si, ... así que procuro no estar a la última en cuanto a driver's y comandos usados. Un saludo y buen FINDE. ------------- Jesús Mansilla Castells. Saludos desde Móstoles. http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones http://www.tecsys.es" rel="nofollow - Tecsys.es |