MSSQL - Al exportar tabla, pierdo IDENTITY

[AlZuwaga]

El tema es el del título. Explico:

Tengo 2 servidores: 1 de desarrollo y 1 de producción.

En el serv de desarrollo tengo una tabla que tiene un campo llamado 'id' (int) Identidad=Sí inicializado e incrementado en 1

Ok, quiero exportar esa tabla hacia una BD ubicada en el servidor de producción. Esta tabla no existe aún en ese servidor. Los pasos que sigo son los siguientes (los aclaro porque no sé si son correctos):

En BD origen:
1- Tabla -> Todas las tareas -> exportar (se abre el asistente para la importación/exportación DTS). Presiono siguiente.
2- Selecciono el origen de datos, el servidor y la BD (que por default me trae la BD origen). Click en siguiente.
3- Selecciono el destino, servidor y BD. Click en siguiente.
4- "Copiar las tablas y vistas de la base de datos de origen". Click en siguiente.
5- Selecciono la tabla que quiero exportar a la BD destino. Click en siguiente.
6- Está sólo marcado "Ejecutar inmediatamente". Click en siguiente.
7- Click en "...no me acuerdo el nombre del botón...", finaliza, click en "listo" y... listo, se cierra el asistente diciendo que todo es correcto.

Bien, voy a la BD del servidor de producción, hago click derecho sobre la tabla recién importada (previo F5 para actualizar) y... el campo llamado 'id' (int) tiene Identidad=No!!!

Estoy omitiendo algún paso?
Mi sqlsrv está andando mal?
O... simplemente esto es así?

Gracias!

[AlZuwaga]

Intenté hacer lo mismo entre 2 bases del mismo servidor (para descartar que sea un problema entre los dos equipos servidores de BD) y ocurre lo mismo :(

[Mithrandir]

Ese asistente es una porquería. Revisa si copiaste alguna vista y verás que ahora es.... una tabla!!. También has perdido índices, llaves, constraints, triggers, .... En realidad ese asistente únicamente hace un SELECT INTO vil y vulgar. Te recomiendo copiar la db en lugar de exportarla.

En el servidor de pruebas mándala a offline, copia el archivo físicamente al server de produccion y en él, en Databases -> Click derecho -> Attach database -> completa los datos faltantes. Pon especial atencion en la nueva ruta de la DB si es que cambia de directorio.

Con eso tendrás todos los datos íntegros.... aunque revisa los usuarios y verás que han perdido la correspondencia con sus logins. Si llegas a este punto avísanos y te explico la segunda (y ultima) parte.

PD. Mr. Daz, te recuerdo que tenemos un foro de SQL Server exclusivo

[AlZuwaga]

Gracias Mith, ahora no puedo hacerlo ya que estoy en otro lado, pero mañana lo revisaré con cuidado.

Si bien no sé casi nada de SQLSrv, "creo" que estás suponiendo (o soy yo el que supone que suponés ) que tengo acceso físico al HDD del servidor de producción como para copiar el archivo... pero ¡NO, no tengo acceso!

Igual mañana, como te dije, lo seguiré viendo.
Gracias nuevamente y disculpas por el lapsus de colocar el mensaje en la raiz del foro de bases de datos ;)

[Apolo]

Iniciado por Al Zuwaga

Gracias nuevamente y disculpas por el lapsus de colocar el mensaje en la raiz del foro de bases de datos ;)

Error imperdonable para un Moderador, por el cual fue necesario la movilización de una vasta cantidad de recursos de Foros del Web, la intervención de varios Moderadores y la utilización de varias opciones de configuración de vBulletin.

Ahh, pero no te preocupes, no hay resentimientos, y además nadie más se enterará de este percance (excepto, claro, los cientos de usuarios que pueden estar leyendo este tema y lo continuarán leyendo a través del tiempo...) :-p :D

[AlZuwaga]

Me parece que hubo una interferencia

Bueno, definitivamente no puedo hacer eso que me comentás, Mith :(
Yo no sé si lo estamos planteando bien, pero el asunto es el siguiente.

En el serv de producción (cuya finalidad es alimentar un sitio web) existirán tablas que se deberán actualizar o sincronizar con los datos existentes en el serv de desarrollo (que es en donde los datos se manejan).

Además, existen tablas cuyos datos se actualizaran en el srv de producción por una persona que trabajará a distancia y es éste servidor quien "es visible desde afuera" (no así el de desarrollo, que está en una red interna sin acceso desde el exterior). Entonces, se necesitaría el procedimiento inverso: cada cierto tiempo, actualizar o sincronizar esas tablas desde el serv de prod al de desarrollo.

Estoy seguro que debe haber una solución al respecto, pero la verdad que escapa a mis conocimientos!

Saludos

[AlZuwaga]

Finalmente a la solución que llegamos es la siguiente:

1- Las tablas que se actualicen en el serv producción (al que se tiene acceso desde afuera), se crean en él con los campos IDENTITY que sean necesarios. Luego se importan a la BD del serv desarrollo (a manera de "otro back-up") y no importa si éstos campos pierden su condición de identidad.

2- El proceso inverso para las tablas que se actualicen en desarrollo (desde "adentro"). Una vez exportados a la BD de producción (para ser visualizados en el la web), no importa si los campos IDENTITY pierden la identidad, la cordura y la capacidad de raciocinio y son arrestados y llevados a un hospital neurosiquiátrico en donde se les colocará un chaleco de fuerza para ser internados en una habitación con paredes y piso acolchados para toda la eternidad.

Será una solución pedorra, puede ser, pero es la más fácil que se nos ocurrió (y la primera :p)

[Mithrandir]

Me perdí. ¿Necesitas mandar datos de producción a pruebas y de pruebas a producción o solo en un sentido?

¿Las actualizaciones son parciales (dejas los datos anteriores) o totales (borras lo anterior)?

..En fin, aunque dices que ya está resuelto me he quedado con la curiosidad

PD. Prepárate para el cargo por los recursos de FDW, se descontará de tu salario de moderador. Seguramente el bajón de rendimiento de ayer fué por tu culpa

[AlZuwaga]

En los dos sentidos.
En realidad sólo un sentido es absolutamente necesario: De "pruebas" a producción (para decirlo de otra manera, de servidor "interno" -quién alimenta la intranet- a servidor "externo" -quien publica en internet algunos datos-)

El otro sentido, de producción a "pruebas", es sólo para que esa info esté disponible tambien dentro de la red local.

¿Las actualizaciones son parciales (dejas los datos anteriores) o totales (borras lo anterior)?

Acá soy yo el que no te entiende (seguramente por desconocimiento), pero yo diría que son acumulativas (en realidad, con el procedimiento que describí, la idea es ir incrementando pero sobreescribiendo la totalidad de la información... creo )


¿Salario de moderador? ¿En serio? Nunca me pagaron nada :llorar: (aunque lo bueno será cobrar los retroactivos :p)

[Mithrandir]

Si sobreescribes todos los datos viejos entonces es total. Ejm: tabla A tenía 1,2,3. Para actualizar borras 1,2,3 y escribes 1,2,3,4,5. Sería parcial si dejas 1,2,3 y solo agregas 4,5

... Espero haberme expresado coherentemente.

Si la estructura de la tabla no cambia, solo los datos entonces puedes probar con los INSERT INTO:

Total:

Código:

TRUNCATE TABLE tabla

INSERT INTO tabla
SELECT t.* FROM servidor.midb.dbo.tabla t

Parcial:

Código:

INSERT INTO tabla
SELECT t.* FROM servidor.midb.dbo.tabla t
WHERE t.llave = 'el filtro con el que conoces los nuevos registros'