SoloCodigo

el libro mencionado, no sirve, en ninguna parte explica acerca de como bloquear los registros.- si alguien tiene alguna idea, por favor comentela yo trabajo con
sql server y c++ builder

Estimado mumo, es una pena leer mensajes como el tuyo...y te lo digo porque mi comentario esta basado en argumentos.

Si leiste un poco , te habras dado cuenta que en un servidor de base de datos entran en juego las transacciones.... dichas transacciones son las que se encargan de bloquear los registros dependiendo de como las configures.

Ahora si quieres hacerlo a la antigua, pues create un campo booleano o numerico que te sirva como bandera para indicarte si el registro esta bloqueado....solo que... ojo.... si tu aplicación se cuelga por alguna circunstancia y el campo se queda indicando que el registro esta bloqueado, la próxima vez que intentes modificar o accesar a el, tu programa te indicará que el registro esta siendo utilizado por otro "usuario" lo cual no es netamente cierto. Tendrás que actualizarlo a mano. Como veras esto tiene serias consecuencias.

Asi es que te recomiendo leer más acerca de las transacciones, verás que te sacan de muchos apuros.

Por ultimo en la pag. 133 de dicho libro puedes encontrar lo siguiente (por si no lo viste)

Registros de transacciones y bloqueos

¿Cómo logran los sistemas de gestión de bases de datos que dos transacciones concurrentes no se estorben entre sí? La mayor parte de los sistemas, cuya arquitectura está basada en el arquetípico System R, utilizan técnicas basadas en bloqueos. Más adelante, al estudiar cómo se actualizan registros con C++ Builder, descubriremos que Paradox y dBase utilizan también bloqueos para garantizar el acceso exclusivo a registros, implementando un control de concurrencia pesimista . Sin embargo, aunque también se trata de “bloqueos”, el significado de los mismos es bastante diferente al que tienen en los sistemas SQL. Ahora veremos solamente cómo se adapta este mecanismo de sincronización a la implementación de transacciones.

En primer lugar, ¿cómo evitar las “lecturas sucias”? Existen dos técnicas básicas. La
más sencilla consiste en “marcar” el registro que modifica una transacción como
“sucio”, hasta que la transacción confirme o anule sus grabaciones. A esta marca es
lo que se le llama “bloqueo”. Si otra transacción intenta leer el valor del registro, se le hace esperar hasta que desaparezca la marca sobre el registro. Por supuesto, esta política se basa en un comportamiento “decente” por parte de las transacciones que modifican registros: no deben dejarse cambios sin confirmar o anular por períodos de tiempo prolongados.

Ahora bien, ¿cómo es que la transacción que realiza el cambio restaura el valor original del registro si se decide su anulación? Lo más frecuente, en los sistemas inspirados por System R, es encontrar implementaciones basadas en registros de transacciones (transaction logs). Estos registros de transacciones son ficheros en los cuales se graban secuencialmente las operaciones necesarias para deshacer las transacciones no terminadas.

Algunos guardan en el log el valor original; otros, por el contrario, guardan el
nuevo valor no confirmado, y lo transfieren a la base de datos solamente al confirmarse la transacción. En la teoría de bases de datos, hablaríamos de undo y redo logs (registros para deshacer o rehacer). Cada técnica tiene sus ventajas y desventajas: por ejemplo, si se utiliza un registro de rehacer y alguien corta la corriente, la base de datos no queda afectada, y al volver a encender el sistema podemos seguir trabajando sobre un estado consistente. Sin embargo, la aplicación de los cambios durante la confirmación es sumamente peligrosa, y el implementador debe tomar precauciones extraordinarias.

Esto nos da una idea para otra política de acceso: si una aplicación, al intentar leer un registro, encuentra que ha sido modificado, puede ir a buscar el valor original. Si utilizamos un redo log, el valor es el que se encuentra dentro del propio registro. En caso contrario, hay que buscarlo en el registro de transacciones. Por supuesto, esta técnica es superior a la anterior, pues ofrece mejores tiempos de acceso incluso en caso de modificaciones frecuentes.

Paradox y dBase implementan un undo log, pero cuando una aplicación lee un registro modificado por otra transacción, no se toma la molestia de buscar el valor
original en el log file. Por este motivo es que aparecen lecturas sucias.

Todos los bloqueos impuestos por una transacción, por supuesto, son liberados al
terminar ésta, ya sea confirmando o anulando.

Que tal Yoda665,

bajate de aquí un ejemplo

http://adrian.org.ar/dat/iptrans%201_0_4.zip

Son dos componentes cliente - servidor, que implementan un protocolo que paquetizan el archivo y lo transmiten utilizando corrección de errores.

Funciona bien para archivos chicos, pruebalo para archivos más grandes, también tendrías que setear alguna opción de reenvío.

Este ejemplo lo encontré en otro foro, asi es que el crédito no es mio (pero no está de más mencionarlo), de igual forma te puede servir para lo que necesitas.

Saludos.

Saludos...

Bien, en al archivo .h que es donde esta declada la clase tenemos algo como lo siguiente...


Como puedes observar las clases entre otras cosas delaran una parte "privada" y otro parte "publica". Todas las declaraciones que hagas en la parte "privada" solo estarán visibles para la clase misma, y todas las declaraciones que hagas en la parte "publica" estaran visibles para el resto de los objetos.

Ej.


Si intentas accesar a "MiVariablePrivada" el compilador te marcará un error.


Y no hay nada que disculpar, todos pasamos por lo mismo cuando empezamos algo nuevo...y aqui estamos para apoyarnos.