Cambios en formularios en VB.NET

radykal

Buenos días,

Hace unos meses hice un programa de gestión en VB.NET para la empresa para la que trabajo (es una PYME) , se encarga de gestionar reparaciones, presupuestos, facturación y clientes (vamos lo muy básico para de una ojeada llevar un control de todo). La cuestión es que hay usuarios algo torpes que suelen cagarla a la hora de modificar cosas, que se equivocan y tal.
Hasta ahora los cambios se guardaban en tiempo real, conforme modificabas cualquier cosa de un formulario actualizaba su campo en la base de datos.
Ahora mi jefe me ha pedido si podría ser posible que cuando se trabaja con un formulario no se guarde nada hasta que al salir se le pregunte al usuario. Esto seria fácil excepto porque según que modificaciones hacen recargar el formulario y necesito que no se pierda lo que haya estado modificando el usuario hasta el momento, aunque no actualice la base de datos.
Había pensado en tener tablas temporales en las que cargar los datos mientras se trabaja con ellos y en caso de querer guardar finalmente trasladar esa información a las tablas definitivas pero no se si es muy correcto o algo chapucero.

Os pongo un ejemplo del por qué de la complicación, ya que mis nociones de programación son mínimas:

Tenemos el formulario que contiene una factura. Por un lado tenemos los datos del cliente y en un groupbox acumulo los textbox referentes a los conceptos y precios de esa factura. Cuando añado una linea nueva o borro una existente modifico la base de datos, limpio y cargo de nuevo el groupbox con los datos actualizados de la base de datos. Estoy seguro que mi forma de operar no es la correcta pero hasta ahora iba tirando así.

¿Alguien me arroja algo de luz acerca de como modificarlo en base a lo planteado? Con una teoría base ya me buscaría la vida para hacerlo funcionar.

NeB1

#1 buf... la idea de trabajar con una tabla auxiliar temporal no es mala idea la verdad, es lo primero que habría pensado yo tmb.

También puedes provar a hacer la consulta de "SELECT" una vez solo, y guardarla en memoria, que el programa compruebe si ya has hecho la consulta o no, en caso afirmativo, trabaja sobre los datos que tiene en memoria, en caso negativo (es la primera consulta) guarda los datos en memoria (un array o algo nuse)

SeiYa

Puedes crear dinámicamente esas líneas de facturas sin necesidad de hacer un insert en la base de datos y que el groupbox lea de bbdd no me parece lo más correcto la verdad.

radykal

#3 puedes explicarte un poco mejor? Soy algo torpe... y mis conocimientos muy limitados :(

pRAXIS

Por lo que he podido deducir utlizas winforms. Si lo que quieres es que se persistan los datos una única vez cuando el usuario termine o cierre la factura, lo que debes hacer es al abrir un cliente recuperar de base de datos o de una cache los conceptos y los datos asociados del cliente, una vez tengas el formulario cargado puedes hacer todo el trabajo sin necesidad de llamar a la base de datos y luego al terminar guardar todos los cambios.

Una buena forma es que te crees un modelo de clases sencillo pero en el que puedas almacenar los datos que necesites, una clase cliente con sus datos, una clase concepto donde meterias un concepto y luego una Lista de conceptos que contendría todos los conceptos. A la hora de guardar sólo tendrías que abrir una conexión y realizar el insert o el update en la tabla cliente y luego tantos insert o update en la tabla conceptos como conceptos tenga ese cliente.

Echale un ojo a la clase DataSet y a DataAdapter (SqlDataAdapter para sqlserver, OraDataAdapter para oracle...), un dataset guarda una estructura de base de datos, y con el dataapapter lees de base de datos y te crea un dataset a este dataset trabaja sin conexión a la base de datos y puedes añadir, modificar, borrar filas y a la hora de guardarlo en base de datos te lo haría el solito, modificaría lo que tuviera que hacer y crearia o borraria filas.

Espero que te sirva

radykal

#5 Muchas gracias voy a mirar lo del dataadapter para SQL Server que es mi caso a ver si me aclaro y soy capaz de hacerlo funcionar.

Soltrac

Datasets, empápate de ellos.

Son como tablas, pero en vez de en BD, están en memoria.

C

#1, tablas temporales es la opción que yo seguiría. Aunque como bien te han comentado al final, ya que estás con .NET, tienes la ventaja de tener DataSet sin conexión a la dB. Sospecho que por la pregunta que haces estás funcionando en modo Conectado continuamente, a la antigua usanza y como, no nos engañemos, siguen funcionando el 90% de las aplicaciones comerciales.

Sin embargo, haz uso de los DataSet desconectados como almacén de datos para guardarlo todo y luego volcar la información a la dB.

Aun así, cuando he tenido que hacer eso en las aplicaciones que he desarrollado, es un auténtico coñazo. Y mira que donde yo desarrollo manejar una base de datos es bastante menos tedioso que en .NET puesto que viene con una capa de datos incorporado que facilita las cosas. Pero aun así... un coñazo.

Lo más peligroso de estos procesos es que se queden a medias. Me explico: Normalmente lo que se hace es marcar a la entrada de la edición del formulario los datos que están detrás con alguna columna de la tabla que así lo indique. Si el usuario acepta, lo suyo es insertar los datos de nuevo, y una vez comprobada que la inserción es correcta, borrar los datos marcados. El peligro en este caso es que haya alguna caída por medio en la conexión. Aunque si lo haces así, en el peor de los casos siempre conservarás los antiguos, puesto que si controlas el pete de inserción, no procederás a borrar los datos previos.

He aquí el coñazo de desarrollar aplicaciones de gestión xD

P.D.: De transacciones mejor no hablo. Es muy fácil soltar esa palabra, pero luego aplicarla no tanto.

radykal

Mmmh he empezado a mirar esto de los datasets y tengo una duda... alguna de las tablas dentro de la misma tienen campos relacionados entre ellas, digamos que dentro de la tabla conceptos tengo un campo que es id_concepto_principal si es 0 ese concepto es principal y si es secundario ahi se introduce la id de su concepto principal (para luego crear el árbol). A la hora de actualizar con nuevos conceptos principales y sus secundarios desde un dataset como asignaria su primary key que es un autoincrementable y sabria luego actualizar el cambio id_concepto_principal en base al número autoasignado ? Ah, la aplicación se abre desde el servidor y normalmente hay 4 o 5 personas trabajando con ella a la vez y pudiendo acceder a la misma información.

Soltrac

SCOPE_IDENTITY si no recuerdo mal..... (Siempre q hablemos de SQL Server claro)

radykal

Bueno, gracias a todos por las respuestas.

Al final he recurrido al mal uso de tablas "temporales" (lo pongo así porque no son bien bien temporales). He creado un duplicado de la estructura de las tablas que necesitaba trabajar sin modificar añadiéndole unos campos de control. Cuando carga el formulario copia los datos que necesita sobre estas tablas con unos identificadores de sesión (por si hay varios usuarios sobre la misma tabla). Todas las acciones que se hacen las actualizo sobre esa tabla y si finalmente se han de guardar los cambios mirando los campos de control que me indican si ha habido cambios, inserciones o lineas borradas actualizo la base de datos original según necesite. Creo que es algo chapucero pero el cambio a hacerlo con datasets me hacia reescribir demasiado y como es una pequeña empresa el rendimiento de la base de datos no se verá mermado por trabajar más sobre ella.

Usuarios habituales

  • radykal
  • Soltrac
  • pRAXIS
  • SeiYa
  • NeB1