Eliminar registros definitivamente sin usar PACK

[Mario Escudero]

Buenos dias a todos:

Existe alguna forma de eliminar registros de una tabla en forma definitiva sin tener que hacer PACK despues de DELETE ? (Idem SQL...)

Probé con DELETE FROM pero igual sólo los deja marcados para usar Pack.

Gracias de antemano por sus valiosos aportes.

Saludos

[Jose Mario]

es como ir al cielo sin morirse

[Fernando D. Bozzo]

En un DBF de Fox/xBase no, porque es parte del diseño el no borrar definitivamante.
La alternativa a no usar PACK, es cambiar de base de datos.


Saludos.-

[Mario Escudero]

Eso mismo pensé Fernando. Estaba pensando en Sql pero eso implica programar bajo n-capas. Sé cómo hacerlo, lo malo es que por ahora el tiempo me apremia.
Gracias
Saludos

Mario Escudero
Rpm #995817087
www.cheff2000.com

Enviado desde mi móvil

[Carton Jeston (9.0.0.7423)]

Creo que un pack en un dbf no es mas que ... set deleted on+copy to +delete file+rename :D

Desde luego asi se puede tener mas control y hacer algun apaño para que no tenga que hacerse en modo exclusivo, aunque yo prefiero hacer un mantenimiento rapido con el primer arranque del dia o semana y permanezca un momento haciendo el pack.

Todo depende del tiempo que lleve hacerlo o el tamaño que ocupe, hace que para unos no tenga importancia y para otros sea un problema de primera magnitud.

[Carton Jeston (9.0.0.7423)]

Mario, si no tienes tiempo, no te compliques, puedes hacer que cuando el ultimo usuario  salga de la aplicacion (si es multipuesto) pones un mensaje de que se estan cerrando las bases de datos y le metes el pack a todas las tablas.

Eso si, tienes que abrir una hacerle el pack y asi sucesivamente. No se si habra un proceso mas sencillo pero creo que no. Mi consejo es que si no tienes tiempo, haz que funcione del modo mas rudimentario y cuando tengas tiempo y sin prisa investigas soluciones mejores :D

El miércoles, 25 de noviembre de 2015, 13:55:04 (UTC+1), Mario Escudero escribió:

[Antonio Meza]

Es mejor una opción de Reindexar el sistema y ahí mismo aplicar el PACK a todas las tablas, y este proceso hacerlo en modo mantenimiento de la aplicación, es decir que solo un usuario tenga privilegios para realizarlo y que el programe ese mantenimiento.

saludos

Antonio Meza

[Carton Jeston (9.0.0.7423)]

Esa es la opcion tipica que todos usamos, de vez en cuando o cuando surge un problema, la aplicacion tiene el boton de "reparar" :D  Yo entendi que queria hacer algo transparente al usuario o igual lo entendi mal ;)

En un caso asi, es mejor hacer un prg que haga el pack, asi puede hacer un boton que ejecuta el prg cuando lo necesita el usuario y ademas puedes poner una opcion en la configuaracion de tu aplicacion para que automaticamente al salir ejecute el pack si asi lo deseas.

[Mario Oviedo]

es mejor un pack programado una vez por semana, a la hora de ir almorzar, por ejemplo y las tablas se limpian de esos marcados, 

porque no al ingresar y porque no al finalizar

porque al ingresar ya hay personas anciosas de querer utilizar el sistema

y al terminar todos se quieren ir rapido a la casa o los deja el transporte

[Carton Jeston (9.0.0.7423)]

Totalmente de acuerdo, de hecho los backups automaticos que duran menos de medio minuto lo hago al iniciar el primer pc... hasta 10 o 15 minutos que tardan en ponerse en marcha de media, hay margen de sobra :)

[arti...@gmail.com]

Yo lo tengo programado al entrar en la aplicación, se hace automáticamente una vez al día,

[Mario Oviedo]

y si es base de supermercado

[Carlos Miguel FARIAS]

Si no es necesario mantener el orden de los registros que se cargan, una manera de no tener que borrar físicamente registros, es reutilizarlos (onda verde reciclado 🐼).

Una manera de reutilizar es hacerle un delete normal (queda registro marcado), pasar todos los campos a valor null, cero, falso, blanco, etc. dentro de lo posible y que no cree conflictos de clave única. Y a la clave primaria llevarla a un valor "extraño".

Si la clave primaria es numérica son valores positivos, ponerle un valor negativo, si es alfanumérica, ponerle caracteres extraños.

De esa manera, con filtros simples, esos registros se omiten del proceso normal. Luego al agregar "nuevos" registros, primero buscas uno que esté "deleted" y haces un update sobre el registro, reemplazando los datos vacíos por los del nuevo registro.

Si no tienes registros re-utilizables, insertas directamente.

Si usas autoincremental, no tienes que reemplazar la clave primaria. Por supuesto que si usas una PK de ese tipo, al momento de la baja habrás hecho una limpieza de otras tablas donde se usa como foránea en forma apropiada, porque si no, te traerá registros "fantasma" relacionados.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad.

Que la Fuerza los acompañe.

[Martín E. Lezama]

Yo no packeo nunca registros, porque además, nunca utilizo el DELETE para borrar registros.

Francamente, no me gusta trabajar con DELETE y registros borrados. Se depende del estado del SET DELETED, se tiene que hacer mantenimiento, etc. etc. etc., y fundamentalmente, mi principal pero pasa porque uno pierde historial cuando borra definitivamente registros.

Les planteo un ejemplo, supongamos que yo tengo un padrón de productos, en donde mi artículo 101 es goma de borrar lápiz / tinta Pelikan. OK, supongamos que ese artículo no lo trabajo más desde hace tres años, porque trabajo con otra fábrica de gomas de borrar lápiz / tinta. Si me diesen de baja el artículo 101 y yo utilizo DELETE y PACK para eliminarlo, se pierde el rastro. Cuando después quiero revisar facturas viejas y saber qué le vendí a un cliente viejo para volver a visitarlo a ver si me vuelve a comprar, jamás voy a poder saber qué era el artículo 101, ya que lo eliminé físicamente de la tabla, con lo cual no voy a saber qué productos ofrecerle a mi cliente como alternativa.

Siempre considero conveniente tener un campo baja, que puede ser de dos tipos. Un tipo lógico en el caso de tablas que no requieran mayor detalle, o un date o incluso datetime en tablas más complicadas. Por ejemplo, si yo doy de baja a un empleado, mi campo baja tiene que ser tipo FECHA, para saber desde cuándo deja de pertenecer a la empresa. Y obviamente, nunca eliminarlo de la tabla, ya que ante requerimientos judiciales puedo necesitar tener toda la información de ese empleado.

Después, por dentro del sistema, si en mis padrones hay registros dados de baja (baja = .T.), no los traigo para la selección en el combo, no permito volverlos a elegir para trabajar. Pero el registro sigue estando.

Algunos clientes me han planteado borrar definitivamente esos registros. Cuando insisten demasiado, no hay problema, entro yo y por mantenimiento les hago:
USE productos EXCLUSIVE

DELETE FOR baja

PACK

Y listo. Pero siempre lo hago si no me queda más remedio, y después de advertirle muy bien al cliente que eso le provoca una pérdida en su historial de registros.

Saludos.

[Mario Oviedo]

yo comprendo tu situacion y la considero valida, si tienes un cliente, que adquiria credit constantemente, y cancelo y dejo de ser cliente, porque se murio, 

tampoco se borrara, 

pero da el caso del detalle de articulo de ventas, que no hay en existencia y que ya no lo necesitas, ni convertir en otro, lo que tenes que hacer es eliminar, no le pondras un campo .t.

da el caso si ya esta procesado no lo podes eliminar, lo que haces es hacer devolucion

no lo podes eliminar si ya esta procesado

pero si estas en la parte de ingreso ni la haz impreso, es valido, eliminarla, pero tampoco daras pack a cada momento, porque tenes que parar la produccion, tenes que buscar un momento adecuado.

USE productos EXCLUSIVE

DELETE FOR baja

PACK

[Martín E. Lezama]

No no, a ver... a lo que apunto, si vos eliminás el artículo, y en NINGÚN LADO (ni en el remito ni en la factura) te quedó el nombre del artículo, ¿cómo hacés para saber QUÉ le vendías a un cliente?

Digo, porque es algo muy habitual, que se usa mucho en Argentina. Cuando entra un nuevo vendedor a una empresa, al margen de los clientes que suele traer el mismo vendedor, también se estila darle una lista de clientes viejos que dejaron de comprar. 

Si un cliente dejó de comprar porque se murió, bueno... es irrecuperable jaja. Pero en el caso, supongamos, de un cliente que dejó de comprarte hace 5 años porque había otra empresa que le ofrecía mejores precios... quizás la coyuntura cambió y vos lo podés recuperar. El tema es que TENÉS QUE SABER qué le vendías a ese cliente hace 5 años, para ver qué precios le podés ofrecer ahora en base a la mercadería que siempre te compraba. Y si resulta que un artículo, por el hecho de que lo dejaron de fabricar o porque empezaste a comprarle a otro fabricante, vos lo eliminaste físicamente, cuando después vas a volver a visitarlo, ¿cómo sabés qué eran los artículos 101, 107 y 115, por tirar un ejemplo, si no los tenés ya físicamente en la tabla? Y además, quedás muy mal si vas como nuevo vendedor a un cliente viejo y le decís:

"Estemmmm... ¿usted qué nos compraba a nosotros? Porque me figuran los artículos 101, 107 y 115, pero como ya no los tenemos más y se eliminaron, no sé qué eran".

A este punto quiero llegar.

Lo que se ESTILABA hacer en estos casos es tener una suerte de sistema histórico. Entonces, vos guardabas una copia del sistema con el histórico, yo mismo tenía un área de mantenimiento que transfería a históricos los registros digamos de hace 2 años atrás, y después sí eliminar esos registros y trabajar con bases de datos más chicas, pero teniendo la opción de consulta histórica de información.

Ahora, hoy en día francamente no se estila. Dada la capacidad de almacenamiento de los discos, realmente tiene que ser una empresa MUY GRANDE para que se necesite "bajar" a histórica una información, por más que sea de hace años. Y si las bases de datos se mantienen validadas una vez cada mes o dos meses, y con los índices que sabés que están funcionando bien, francamente en prestaciones no tenés mayores problemas.

Abrazo!

[Mario Oviedo]

no hablo de maestro. hablo de ingreso de datos, 

[Mario Oviedo]

pero tu me hablas, ya procesado, yo no hablo de procesado, 

[Martín E. Lezama]

No entiendo a qué te referís con "ya procesado". Claro, yo me refiero a jamás eliminar registros de un maestro, por ejemplo, porque tu tabla pierde referencia. Si vos tenés el artículo 101 y después ese artículo desapareció del maestro, no tenés contra qué verificarlo.

Pero en general, hay varios motivos por los cuales yo siempre prefiero no borrar para no perder el historial de los registros. Uno sería el ejemplo del que te hablé, es simplemente uno de los ejemplos. Otros tienen que ver con motivos de auditoría.

Yo he trabajado usualmente con mi papá haciendo sistemas. Él no es programador, es contador público. Digamos, él me tiraba los lineamientos generales de lo que tenía que hacer el sistema, y yo llevaba eso a líneas de código. Digamos que él era quien hacía de analista y yo de programador. En general, una norma que SIEMPRE tomamos fue nunca eliminar registros. Marcarlos como dados de baja, como anulados, sí, pero NUNCA eliminar físicamente. Y te agrego más, manejábamos tablas de transacciones, en las cuales grabábamos TODO. O sea, por ejemplo, yo hice un boleto de compra venta de un auto usado (en ese momento él era el contador de una concesionaria automotriz), se grababa el registro y se grababa un registro de transacción con la misma información. Ahora, luego modifiqué ese boleto de compra venta, se modificaba el registro pero se GRABABA UN NUEVO REGISTRO de transacción. Con lo cual teníamos el historial de todo lo que había sucedido con un registro. Obviamente, estas tablas de transacciones se utilizaban solamente para lo operativo, no para un maestro. Pero el motivo era sencillo... muchas veces, se modificaban registros que estaba MAL que se modificasen. Entonces, te quedaba el historial de cómo fue el registro creado originalmente, y cómo fue evolucionando ese registro a lo largo del tiempo. Si hubo una modificación que no correspondía, tenías el nombre del usuario que lo había hecho, entonces, ahí mi viejo los llamaba a la oficina de contaduría y les enseñaba "cuántos pares son tres botas" (y sí, mi papá es un señor muy hincha cocos :D)

Eso que te digo siempre es útil para cualquier tipo de registro que implique DINERO. Porque es en donde tus sistemas más tienen que apretar las cosas para que siempre quede en claro qué es lo que sucedió.

[Jairo Miranda]

La unica manera es dar el delete y despues reemplazar el registro por uno vacio.. al final del dia el sistema haga un pack al terminar.

JM 

[Carlos Miguel FARIAS]

Coincido con Martín. La información no se debería borrar, solo determinar su estado. No se puede plantear excusas de almacenamiento, ni aún en Fox (Euro Tunnel gestionaba con dbfs 100 Gigabytes).

A tener en cuenta, en Argentina, la documentación tienes que mantenerla 5 años por requerimientos de AFIP (Agencia Federal de Ingresos Públicos), ergo, tienes que mantener tus registros informáticos al menos 5 años. Pero desde el punto de vista gerencial, no estaría mal mantenerlos al menos 10 años.

Los datos o maestros o de transacciones, tienen que quedar guardados. Sobre todo si la información quedó documentada por fuera del sistema informático (por ejemplo un impreso).

Contablemente, un asiento erróneo no se borra, se hace contra-asiento, o sea, operación que lo anula o neutraliza, pero no se borra.

Toda la información en la computadora es procesada, si estas cargando una transacción, los registros deberán tener una marca de "en carga", "pendiente", etc. pero no tener la posibilidad de borrarse (y no solo con dbfs, con otros SGBD igual).

El hecho de poder borrar físicamente datos, te produce agujeros de auditoria.

Supongamos. Alguien retira mercadería de un deposito, quedando el retiro registrado (a modo, la encuentra antes de que se pierda), hace algo con ella (fuera misión/visión de la empresa) y a los 20 días la reintegra, y borra el movimiento, hubo algo anormal ahí que se perdió y que auditoria debería haber podido registrar.

Esto parece raro pero les comento algo verídico, paso en un banco aquí en La Pampa.

En épocas de inflación los bancos manejaban depósitos a plazo fijo tan cortos como 7 días. Había un cliente "grande" del banco que por su giro comercial, mantenía sumas elevadas en cuenta corriente. Dado que pagaba con cheques en fechas relativamente ciertas y cobraba sumas significativas periódicamente.

Empleados bancarios, observando los movimientos, hicieron la triquiñuela de retirar fondos de la cuenta corriente del cliente, usando el dinero para crearse "sus plazos fijos", al término de los mismos, embolsaban los intereses y restituían el importe a la cuenta del cliente. En la conciliación bancaria, al cliente le daba el saldo, y no se percataba de la "salida" y "entrada" de fondos.

El control bancario tampoco detectaba nada anormal, porque los valores cerraban, no había reclamos, todo se veía bien.

La estafa se detecta porque el cliente fuera del flujo normal de dinero, libra un cheque "pesado" contra su cuenta corriente, fuera de las fechas habituales, el cheque, es rebotado por "sin fondos" (los fondos se los habían "tomado prestados").

Lógico, el cliente reclama que según sus registros, el cheque al momento del pago tenía fondos, y el banco registraba que no.

Al hacerse los controles de movimientos, le indican al cliente que ha retirado dinero para plazos fijos, lo que el cliente niega y en la investigación posterior, salta el defalco de los empleados bancarios.

La modalidad se puede detectar porque "no hay registros borrados" y que no es una situación casual, si no algo que se repite. Y nos error de sistema, es operación dolosa.

Concluyendo. Solo es admisible borrar físicamente registros, cuando ante una caída de sistema, te quedan transacciones incompletas, y registros con datos destruidos, situación que en dbfs es problemático rehacer si recurrir a deletes y packs.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe

[Mario Oviedo]

SI SOS NECIO, O NO LEES BIEN, SI SOS NECIO

NADIE HABLA DE MAESTROS, NI DE REGISTROS VIEJOS PROCESADOS, 

NI DE REGISTROS YA CONTABILIZADOS, 

HABLO DEL MOMENTO, DEL INSTANTE QUE INGRESAS, AL INSTANTE DEL INGRESO, DE ARTICULOS, QUE NO LOS NECESITAS, PORQUE ALGUIEN SE EQUIVOCO

SESION TERMINADA

[Carlos Miguel FARIAS]

Mario Escudero que no es Oviedo. Te sirvieron las respuestas?

Saludos: Miguel, La Pampa (RA)

[Martín E. Lezama]

Comparto completamente esta postura.

Justamente, los únicos registros que hay que borrar con delete y pack son registros basura. Ejemplo, se cortó la luz y en el momento de la caída, el DBF estaba abierto y te grabó cincuenta y tres registros con basura. Y JUSTAMENTE porque TODOS y cada uno de los registros, a la larga o a la corta, implican DINERO. Ya sea en efectivo o en mercadería. Justamente, yo definitivamente me empecé a dedicar a la programación después de trabajar mucho tiempo en auditorías, tanto contables como de stock. Y eso es la primera precaución que tomé siempre al hacer sistemas.

[Martín E. Lezama]

Hey, me parece que no hay necesidad de gritar ni de tratarme de "necio". Aflojame un poquito los humos porque yo no te agredí, todo lo contrario, estoy tratando de conversar y de buena manera, me parece que no te falté el respeto como para que me contestes así.

Según lo que decís, por ejemplo, vos das de alta el artículo 101, goma de borrar lápiz / tinta Pelikan. Y después ese artículo NUNCA ENTRÓ a tu empresa y nunca lo utilizaste porque fue dado de alta por error.

Ahora bien, NI AÚN ASÍ yo pondría DELETE y PACK. ¿Cuántos casos pueden haber de artículos dados de alta por ERROR? Poquitísimos, porque no se condice con CÓMO se trabaja en las empresas. Por ejemplo, en la empresa en la que estoy trabajando yo ahora (una empresa de limpieza de oficinas y galpones), dan de alta los nuevos productos de limpieza cuando FÍSICAMENTE entraron al stock. En general, en las empresas suele suceder así también.

Ahora, yo me pregunto ¿justifica un error ESPORÁDICO, el hecho de que yo le ponga a un cliente al alcance de su mano el DELETE / PACK y que puedan borrar historiales? Para mí no.

Lo que SÍ me sucede en otro cliente (una casa de artículos eléctricos e iluminación) es que tienen muchísimos productos. Y a veces por error dan de alta un producto que YA ESTABA dado de alta. Eso pasa seguido. Entonces, para esos problemas, yo lo que les puse a su alcance es una FUSIÓN de productos, en donde vos ingresás los dos códigos que querés fusionar, elegís el que querés que quede, y te fusiona las existencias, te fusiona toda la mercadería que salió tanto por remito como por factura, te fusiona los precios al precio que vos elegiste dejar como valor de compra y venta, y al otro producto te lo marca como "baja" (booleano).

Tampoco necesité usar DELETE y PACK. Si bien ahí sí podría borrar ese segundo registro, ya que en este caso todo el historial se fusionó en el artículo que quedó vigente.

[Mario Oviedo]

Según lo que decís, por ejemplo, vos das de alta el artículo 101, goma de borrar lápiz / tinta Pelikan. Y después ese artículo NUNCA ENTRÓ a tu empresa y nunca lo utilizaste porque fue dado de alta por error.

nadie dijo de dar de alta, seguis con lo mismo

estamos suponiendo que estas vendiendo, y ingresastes el codigo 101 y el que esta facturando dijo, no ese articulo no hay en existencia

borralo del pedido

ni a sido ingresado, a la base de datos, solo fue ingresado a pedidos, temporales, entonces hay que eliminarlo

necio no es mala palabra, te tube que deci insistis en lo mismo

en lugar de necio

perdoname

[Martín E. Lezama]

Ahhhhhhhhhhhhh... recién AHORA te entiendo a qué estás apuntando, pero AHÍ NO NECESITÁS delete y pack.

Por ejemplo, vos estás facturando y resulta que no tenés existencia. Lo quitás de la factura. Ahora, eso NUNCA se hace en la tabla DEFINITIVA, José, de ahí viene mi confusión con lo que vos me planteabas.

Yo ni siquiera uso tablas para eso. Uso cursores. Creo un cursor de detalle de facturas, supongamos:

CREATE CURSOR curdetfac (codproducto c(20), descrip c(60), cantidad n(12,3), unitario y, subtotal y, baja l)

= CURSORSETPROP("Buffering",5,"curdetfac")

A medida que van procesando la factura, se van agregando líneas en ese curdetfac. Puedo borrar un registro con baja, recuperarlo si lo borré mal, y todo lo que tenga que hacer.

Después cuando grabo definitivamente la factura, bajo todos los renglones de ese curdetfac a mi tabla de detalle de factura definitivo, y después le mando:

= TABLEREVERT(.T.,"curdetfac")

Como a ese cursor yo lo había puesto en buffering ni bien lo creé, ese comando TABLEREVERT lo que hace es vaciarme ese cursor de registros y dejarlo en blanco para la siguiente factura. Tampoco necesitás delete y pack, SIEMPRE es conveniente usar las funciones de buffering antes que eso, ya que las funciones de buffering trabajan EN RED, en cambio el PACK necesita un uso exclusivo de archivos. Si bien en el caso de una tabla temporaria tendrías el uso exclusivo, es mucho más cómodo el TABLEREVERT ya que en un solo paso te vacía el cursor.

Abrazo.

[Martín E. Lezama]

Es más, probalo desde la línea de comandos. Hacé un CREATE CURSOR y dale la estructura que quieras, y PONELO EN BUFFERING 

= CURSORSETPROP("Buffering",5,"NombreDelCursor")

hacé un BROWSE, agregale registros, marcá registros con DELETE, recuperalos, todo lo que quieras. Y después mandale 

= TABLEREVERT(.T.,"NombreDelCursor")

Vas a ver que es mucho más sencillo que trabajar con temporarios usando delete y pack. Es más ágil y además, te acostumbra a trabajar con esas funciones del VFP que son una verdadera masa.

El miércoles, 9 de diciembre de 2015, 15:18:55 (UTC-3), Jose Mario escribió:

[Miguel A.]

Hola,

Yo ya ni recuerdo de dónde saqué esto, pero tampoco he borrado un registro nunca, simplemente los vacío y, si es el caso, los reutilizo. Claro que ya soy más que de la vieja escuela, un poco fósil, pero siempre me funcionó muy bien todo de esta forma.

Saludos,

Miguel A.

[Mario Oviedo]

como lo vaz a reutilizar si sobra, hay que darle en la nuca

[Miguel A.]

Desgraciadamente ese mismo criterio siguieron algunas dictaduras y ya ves las consecuencias...

Yo creo que al que sobra no hay que matarlo, con apartarlo es suficiente (me estoy refiriendo ahora a los registros)

[Carlos Miguel FARIAS]

Coincidiendo tocayo: Los militares de la última dictadura, reconocen haber hecho desaparecer 8000 personas (les endilgan 30000), en cualquier caso, una barbaridad, pero como buenos "peronistas" (los militares) hicieron las cosas en forma incorregible, y no pueden justificar nada.

Pero ojo, en los últimos 12 años de democracia en al Argentina, hubo más de 2000 desaparecidos y que hicimos/hacemos/haremos?

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los Acompañe, la Pena de Muerte puede que sea justificable en algunos casos (votaría en contra de instrumentarla), pero... no es reversible (no hay RECALL aplicable)

[Daniel Sánchez]

Disculpa Miguel pero con tu ex presidenta yo también me hubiera auto desaparecido..... En cuanto a la pena de muerte no es el fin del mundo, algunos estados de los united states la aplican y no por eso se vuelven barbaros. Como dirían un mal necesario.

Saludos

--

Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil +051-949398047 RPM #948615385
Trujillo - Perú

P  Sugerimos no imprimir este e-mail a menos que sea absolutamente necesario. Protejamos el medio ambiente.

[Carlos Miguel FARIAS]

Por que debería haberme autodesaparecido?

Y la pena de muerte, reduce el delito? Solo reduce la cantidad de delincuentes.

Si no se reduce el delito, no sirve de nada la pena dura o la pena blanda.

Y la falla está en el sistema que hace que la Justicia falle cuando Falla, porque es influenciada por "el poder político" (algo así como el lado oscuro de la Fuerza).

Y el delito debe desaparecer de arriba abajo. Si el de arriba delinque, que le queda al de abajo.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, y que no les hagan delete y pack

[Daniel Sánchez]

Vamos por partes, como decía Jack

1. no dije que tu te auto desaparezcas (era en referencia a las ideología y política aplicada por tu ex presidenta, espero no tocar tu susceptibilidad en caso seas simpatizante) ese comentario fue por el tema de los desaparecidos supuestamente por los gobiernos de turno.

2.En cuanto a que reduce el número de delincuentes si los reduciría (ya que se aplico delete) y por consiguiente el punto 3 también sería afectado ya que al haber menos delincuentes se cometerían menos delitos (lo que reduciría el reccount() de la tabla).

4. Y como todo sistema siempre fallará porque siempre hay un bug (peor si no aplicaste try catch) que no viste y para que evitar que falle el poder debes tener un buen ups.(en cuanto a lado oscuro, no es lo mismo que te agarren el oscuro a la fuerza)

5. En cuanto de arriba a abajo ahí aplicaría las técnicas drill down o de minería de datos.

Y como lo anterior dicho ha sido escrito por un sistema automático de auto respuesta (robot) ignorar lo escrito.

Y por supuesto si no hay plata dele_te y si no un six pack

[Carlos Miguel FARIAS]

Contesto intercalado...

Vamos por partes, como decía Jack

Justamente esta mención va en contra de lo que pones en 2), suponiendo que las prostitutas fueran delincuentes (en muchos casos son victimas), Jack se cargó unas cuantas y no redujo la prostitución.

1. no dije que tu te auto desaparezcas (era en referencia a las ideología y política aplicada por tu ex presidenta, espero no tocar tu susceptibilidad en caso seas simpatizante) ese comentario fue por el tema de los desaparecidos supuestamente por los gobiernos de turno.

A Cristina, siempre que pude la Bote. Al final tuve suerte.

2.En cuanto a que reduce el número de delincuentes si los reduciría (ya que se aplico delete) y por consiguiente el punto 3 también sería afectado ya que al haber menos delincuentes se cometerían menos delitos (lo que reduciría el reccount() de la tabla).

Reducir la cantidad de delincuentes (delete) sería como mandarlos a la cárcel, ya que es un borrado "lógico", y en caso de error, le haces un recall. Pero si haces pack, haces un borrado "físico" y no hay recall con sirva en caso de error (y la justicia aunque trabaje bien, igual Falla), además, al tener que otorgar acceso exclusivo, implica acceso exclusivo, y eso deja a los demás afuera, y a mi me gusta compartir. Y como la muerte no asusta al delincuente, los que quedan lo siguen asiendo (ver caso China, como 2000 sentencias de muerte por año).

4. Y como todo sistema siempre fallará porque siempre hay un bug (peor si no aplicaste try catch) que no viste y para que evitar que falle el poder debes tener un buen ups.(en cuanto a lado oscuro, no es lo mismo que te agarren el oscuro a la fuerza)

Cuando más grande es el bug, por más que TRY la policía apresarlo no logra CATCH el bicho porque FINALLY sale porque tiene $$$. En cuanto a los sistemas de control de errores, prefiero ser proactivo, dejando para los try, aquellos casos que aunque previstos no pueden ser atajados por dentro de la aplicación (por ejemplo, borraron una tabla, virus u humano ;-D)

Y es imperdonable que no compartas el telefono del oscuro de la fuerza

5. En cuanto de arriba a abajo ahí aplicaría las técnicas drill down o de minería de datos.

Esto se lo dejo a los hermanos chilenos, que demostraron que pueden recuperar cualquier cosa de abajo.

Y como lo anterior dicho ha sido escrito por un sistema automático de auto respuesta (robot) ignorar lo escrito.

Esto no me lo creo, hay muy buenos programas de inteligencia artificial (IA, no confundir con ia), pero lejos de lograr un buen programa de HA.

Y por supuesto si no hay plata dele_te y si no un six pack

Lo dele te (o mate/cafe) se entiende, lo de six pack, debe ser aclarado, por lo que indicas en 4, te refieres al six pack del oscuro, o colega estándar a un six pack de cerveza?

Alguien quiere pan casero?

[Daniel Sánchez]

Jajajajajaaj..!!!!!!!!

gracias me alegrastes el lunes.

Saludos

PD. en cuanto al six pack es de cerveza y en cuanto al oscuro con fuerza ya no lo quiero recordar.