Hola ^TiFa^

no quiero abrir un tema nuevo para tratar esto mismo xD

sabes, creo que tu no le ves mucho sentido a lo que plantea diego_lp pero quiza porque hablamos de necesidades distintas, yo comprendo perfectamente el porque diego_lp desea trabajar de esta forma, es algo que yo me pregunte en su momento y me quede igual con la duda xD.

la necesidad (hablando de mi caso particular) es que en donde laboro hay 7 sucursales con 7 bases de datos distintas (una por sucursal) con 7 servidores (uno por sucursal) pero que son servidores solo por tener el sistema windows server y no porque en hardware lo sean, aparte de esto, hay una cede central que si posee un servidor en hardware y sistema operativo, que este tiene los datos de las 7 sucursales, osea la base de datos es muy grande a medida pasa el tiempo, aca nosotros tenes la necesidad (no resuelta xD) de replicar los datos entre estas 7 sucursales entre si, porque si estas en una sucursal (sucursal1), esta tiene que ver la existencia de todas la demas (las 6 restantes) asi como las otras 6 ver las existencias de sucursal1, aparte de esto, la cede central tiene movimientos de ordenes de compras nacionales y extranjeras, y los datos tienen que ser vistos desde las 7 sucursales, porque si algun cliente pregunta si tienen X producto y en ninguna sucursal hay existencia para efectuar un translado, entonces, el cliente pregunta si ya se pidio y cuando entra, por este motivo los datos de la cede central deben estar en las 7 bases de datos, ahora bien, claro que podriamos evitar la redundancia de datos, haciendo que el sistema consulte a la base central, pero no lo hemos hecho de esta forma por una sola razon, el dia que el internet falle nos lloveran puteadas xD y aunque nosotros no tengamos la culpa a ellos no les importa (a los jefes de sucursales) por lo tanto, la unica opcion que encontramos es correr una rutina cada 30 minutos para que los datos entre si solo tengan un retraso de 30 minuto entre sucursales y cede central, ahora bien, esto funciona casi perfectamente, hasta que, por una de esas cosas de la vida, nos dimos cuenta, que en registros "especificos" nos puede ocurrir duplicacion de datos en la base de la cede central, cosa que podemos enmendar siempre y cuando sepamos que origino esta duplicacion, pero la cosa, es que creo que seria mas facil si fuera una replicacion que haga internamente algun motor (MySql en este caso), ya que el motor que nosotros usamos no tiene este funcionalidad, el caso, es que como no sabiamos si esto se puede hacer no le metimos mano, ya que diego_lp lo trae a colacion y puesto que a mi me interesa, me gustaria saber si esto es posible?, necesitamos un motor distinto por el simple hecho de los SELECT, ya que trabajo reportes en los que cuando una tabla pasa de un millon de registros y los filtros al parecer no me funcionan tan bien con un indice compuesto ,me veo en la necesidad de migrar a un motor que sea mucho mejor, en este caso, hemos pensado hacerlo en MySql, dime ^TiFa^, lo que plantee se puede hacer con MySql?

Thks!

salu2

Hola Randomize, solo mencionar que ya lo solucione y vaya si que es una estupidez  

igual te contestare  


La imagen esta en formato ISO


esto es lo curioso, una de esas veces que intente grabarlo, use ultraiso para hacerlo,  el me reconoce 3.67gb, si lo monto con el (ultraiso) igual el peso montado es de 3.67gb , lo monte con el alcohol, deamon tool y es igual, es de 3.67gb, incluso puedo grabarlo en un dvd5 (porque lo hice para probar xD) y la grabacion no da error (lo grabe como tipo data desde la unidad montada).

la cosa, es que, use el ultimo programa que usaria para grabar una iso xD, use nero y  con nero si se graban los 6.28gb del juego, y me fije que nero por defecto selecciona de forma automatica el tipo de libro que usara , y este usa (en este caso) el tipo DVD-ROM, solo por "probar" lo queme por segunda vez usando otro soft seleccionando el tipo de libro DVD-ROM y se grabo perfectamente ¬¬ eso era todo xD

PD: lo realmente curioso por lo menos para mi, es que una vez quemado, al seleccionar todos los archivos dentro del dvd9 y ver su peso, el peso sigue siendo 3.67gb O.o aunque enrealiadad esten quemados mas de 6gb O.o

Gracias Randomiz y gracias chinox por ofrecerte a compartir el juego subiendolo tu mismo

Medio les contare mi historia xD

he bajo el GOD en dvd full (dvd9) dos veces de fuentes distintas

La primera vez que lo hice eran 64 partes de archivos rar, la imagen se creo al descomprimir los archivos, perfectamente.

intente quemar el dvd9 4 veces y las 4 fueron fallidas, mi quemador si soporta el quemado en dvd9, el error "era inesperado"

como me paso las 4 veces lo mismo, se me ocurrio entonces montar la imagen iso en una unidad virtual (estando en windows), y en linux lo he montado con mount -o loop y en ambos casos el peso una vez montado es de 3.67gb O.O

pense que aunque no hubiera error alguno en la iso, "quiza" estuviera dañada, asi que procedi a bajar la Iso desde otras fuentes, esta vez fueron 68 partes y con contraseña (lo menciono para hacer obvio que no baje lo mismo por culpa de un copy-paste xD )

me ha pasado exactamente lo mismo, entonces, ahora me he puesto a pensar que la Iso anterior y esta nueva Iso estan correctas, el problema es que desconozco como quemar este juego en especifico, puesto que tengo otros juegos en dvd9 y los puedo montar y especificamente pesan lo que la iso dice.

Ahora bien, nose cuantos de ustedes han pasado por esto mismo, hay un archivo que se llama PART1.PAK y por este nombre de archivo pense que la iso estaba mala, puesto que este es el archivo que pesa 3.67 y los demas archivos pesan unos pocos kb cada uno, la cosa, es que he pensado tambien, que este archivo al pesar mas de 2gb se debe montar de forma distinta, ahora la pregunta que tengo es, como demonios lo quemo? xD y si quemado no abria problemas, porque se "supone" que es un dvd9, tambien me parece "curioso" que haya una archivo que se llama PART1.PAK sin haber otro que se llame PART2.PAK xD

salu2

enrealidad no es el "truco" de la negrita, es el "truco" de usar etiquetas  prueba con otras, veras que funciona

sin duda muy buena info, aunque creo que hay una gama mas grande de gente mal hablada y traducir terminos inventados esta dificil xD , pense que al copiar un dvd9 en un dvd5 eso tambien se llamaria dvd-rip, porque la accion de copiarlo al disco duro es a lo que se le llama ripeo, ojala y songoku se pase por aca y nos aclare futuras dudas 

Gracias T0rete

que curioso, a mi tambien se me ocurrio lo de la vista xD ,pero la deseche porque no estara siempre actualizada por lo menos, yo para actualizar uso REQUERY( ), entonces, dije, bah, en lugar de hacer 3 consulta 1) para actualizar la vista , 2) la que necesito y 3) la subconsulta, decide hacerlo de la forma que lo postee xD, aunque como tu dices para los gustos los colores, el caso es que esta resuelto 

nose, yo lo decia mas bien por otro lado xD , osea como que el numero de factura sea 0001, y evalues simplemente que esa factura exista en las tablas separadas, pero que exista no quiere decir que sea la misma porque el valor puede ser distinto asi como la Serie de la factura, mas bien por ese lado iba yo, aunque si tu y el recalcan el unico entonces supongo que ya no desea Reevaluar, mas bien yo lo decia por el lado de la Reevaluacion y lo digo porque el dice que la tabla completa esta unica (que entendi no la hizo el sino que se la dieron), pero no asi las separadas y que el separo con DISTINCT, y si fuese por ejemplo como el caso de una factura, ese DISTINCT me podria mentir, no lo he dicho por contradecirte ^TiFa^   

дٳŦ٭ depende si estamos hablando de datos de una tabla padre, porque en un tabla padre los datos practicamente no se repiten y no me refiero puramente al ID, pero si es una tabla Muchos, los datos se repiten y como sabras, aunque filtres por una subconsulta como lo hace ^TiFa^ el resultado seria erroneo, porque supon que tiene un codigo X en la tabla muchos, tal y como lo hace ^TiFa^ con una vez que aparezca el codigo X se jode el resultado, porque abria que ver cuantas veces deberia de estar dicho codigo X en tu tabla completa y tantas veces deberia de estar en las tablas separadas que tienes y que los datos sean identicos y suponiendo que sean resultados numericos, la suma deberia ser la misma, por eso, yo antes de intentar dar una solucion desearia que nos aclaremos el panorama que tienes con tus tablas y asi intentar ayudarte

o todo se rige por el correlativo? o podria ser que el correlativo de una no concuerde con la que esta completa?, o al concordar supuestamente estarian bien los datos? y solo buscariamos los correlativos faltantes?

yo lo haria de esta forma, los campos se llaman distinto pero la idea se entiende

SELECT COUNT(codigo) veces, codigo FROM saldos GROUP BY codigo ORDER BY veces DESC 
variable = query.veces
SELECT * FROM query WHERE veces = variable
 

si ordeno el resultado de forma descendente, se que el primer registro del cursor sera el mayor o igual, entonces lo capturo en una  variable, luego hago una segunda consulta al resultado anterior y le filtro el campo veces, de este modo, no importara cuantas veces aparecezca, me lo tomara todas, nose si me di a entender xD

en una sola consulta creo que no se puede, lo intente de varias formas :/ 

aca
http://foro.elhacker.net/seriespeliculasmusica/serie_anime_dragon_ball_gt_catala-t206397.0.html

podrias usar el indice  xD