Mensajes

Hola
El ultimo paso esta mal, yo tengo la version en ingles, y tu en español.


El tuyo tentativemente la ruta debe ser asi.


Presiona los botoncitos que tiene 3 puntitos al costado de la ruta y busca una carpeta similar a la ruta anterior C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data

tus rutas deben quedar

C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ticom.mdf
C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ticom_log.mdf


atte.
Miguel Angel

HOLA AMIGO, ME DICES QUE CREE una carpeta de nombre BASES DE DATOS en mi disco C y q debo poner en este archivo xq esta en blanco

Hola.

Crea la Carpeta BASES DE DATOS en C

y luego en las opciones de restauracion asegurate que te queden como lo remarcado en rojo y luego le das aceptar.



Atte.
Miguel Angel

hize tal y como me indicaste busque los archivos .mdf y .ldf  pero porque me sigue saliendo error http://img412.imageshack.us/img412/7204/23071265.jpg .........porfavor  DONDE ESTA EL ERROR ayudenme necesito resolver este inconveniente YA .....AYUDENMEEEEE  

Hola.

Lo mas probable que estes colocando mal la ruta donde se encuentre la base de datos creada y mas el nombre de los dispositivos mdf y ldf.

Busca la Ruta donde se encuentran los archivos .mdf y .ldf de la base ticom, y ademas en opciones marca el check Sobre escribir la base de datos existente.

si no te funciona has lo siguiente.

Paso a Paso.

Restaurando la base de datos base de datos.

Borra la Base de Datos ticom.

Asumiendo que la base de datos que quieres restaurar es ticom, como en tu ejemplo, en este caso el nombre de mi backup es pyr_riscal_cfg_161109.bak

Paso 1. Ubicando Backup.

a) Para esto no crees ninguna base  de datos situate en la carpetaCarpeta Base de datos click derecho y presiona restaurar.


b)
Ponle el nombre a la base de datos en este caso ticom y ubica el archivo de BD.


c)
Crea una Carpeta en tu disco C y colocale nombre BASES DE DATOS, en la imagen marcado con el cuadrado en rojo te mostrar una ventana de seleccion busca la carpeta creada, colocale un "\"  y escribe ticom.mdf ; para la segunta linea lo mismo pero en lugar de poner ticom.mdf pon ticom_log.ldf


d)
Presiona ok y ya.





atte.
Miguel Angel

En Opciones tienes que buscar los archivos .mdf y .ldf de la base de datos, generalmente cuando las creas se encuentran en:

C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data\

Una vez seleccionados recien le das aceptar.

atte.
Miguel Angel

Q error te muestra?

Cuestion de gustos, ni mas ni menos, nadie te obliga a usar CHAR eres libre de seguir utilizando varchar en todas las referencias que desees. Lo que no puedes es discutir entre char vs varchar cuando te hago una referencia publica de una fuente muy respetada (existen mas) del porque es mejor usar CHAR aveces ante VARCHAR, despues de ahi si quieres obviar char para cualquier campo aun conociendo su longitud exacta, ya no puedo hacer nada yo.

Estimada Tifa, eso no es discutible ya que como te recalco no es cuestion de gustos la eleccion del tipo de dato para un campo, es asi como se hace la eleccion del tipo de dato, se elige el tipo de acuerdo al comportamiento que va a taner, si conoces la logitud exacta pues lo mas logico es usar char, si la logitud del campo es variable pues lo mas logico es usar varchar; pero esto es relativo..

El Manejo de Niveles de Aislamiento dan para otro ilo, que no tienen nada que ver con lo expuesto y desvirtuarlo mas de lo que esta.

Hola de nuevo, no te respondi por el tiempo que tengo muy limitado en el trabajo y solo dispongo de fines de semana, iniciamos.

Para la suposicion que mencionas de la corrupcion para el campo varchar no es dable, ya que la ATOMICIDAD de una transaccion garantiza que los datos se guarden de manera correcta o no se guarden y no por partes como seria lo que supones, en caso de suceder es un problema de la transaccion mas no del tipo de dato, si un motor de base de datos no puede manejar eso es un desastre transaccionalmente hablando..

Ahora, ya que haces una fuerte referencia sobre la garantia de atomicidad que debe ofrecerme un motor en cuestion por ser transacional, yo te pregunto en un valor declarado como VARCHAR (10) tu considera este valor atomico cuando se puede descomponer la cadena en caracteres individuales? Atomicidad de Valor de los datos (No del motor de almacenamiento que lo gestiona) por sí mismo no es un criterio objetivo y no tiene ningún significado absoluto.

Bajo el contexto que pones CHAR tambien no seria atomico ya que se puede subdividir en cadenas de caracteres individuales para lo cual seria el tratamiendo de la misma manera de un varchar.

la atomicidad puede tener muchas interpretaciones distintas, pero un motor no puede asegurarme 100% atomicidad cuando posee por ejemplo un tipo de dato varchar (con las caracteristicas antes mencionadas por mi) porque si fuesen 100% atomicos ninguna tabla se corrompiese jamas.

1ro. Confundes las cosas, una cosa es atomicidad de un campo de una tabla y otra muy distinta es la de una transaccion asumo que sabes que es ACID de una transaccion.

2do. El motor tiene que garantizarme la atomicidad de una transaccion al 100% ya que si no lo hace, ese motor de datos es una porqueria independientemente del motor de datos que sea, con un Ejemplo:

Si un motor me garantiza 99% de atomicidad transaccional refiriendonos a manipulacion de registros, quiere decir que de cada 100 registros afectados (INSERT, UPDATE, etc..) va a fallar 1, ese 1 lo cual es demasiado, sino exagerado,e inaceptable las unicas veces que he visto corrupcion de datos/tablas ilegibles y sus variantes fueron cuando los discos fallaron, por eso se me hizo raro que mencionaras corrupcion de tablas esto te lo podria aceptar cuando se usaban intensamente DBFs, en los tiempos de clipper o foxpro pues esos eran mas propensos a corrupcion de cualquier cosa.

3do. Mencionas la corrupcion de tablas como si fuera algo diario o algo muy ocurrente, no soy DBA,  soy conultor y auditor de sistemas, si un DBA de alguna empresa a la cual auditamos y desarrollamos soluciones nos menciona casos de corrupcion de tablas muy recurrentemente, pues el problema es el DBA, y pues como con la mayoria de los problemas este se depura.

4to. Para Mi, el unico desencadenante para elegir el tipo de datos CHAR o VARCHAR es basicamente en como almacenan los datos, uno estaticamente y el otro dinamicamente, que uno es mas tolerante a la corrupcion talvez.., pero no me parece un motivo desencadenante y es  irrelevante para esta tarea ya que la corrupcion debe ser minima.

Ya que al menos en los motores de base de datos que conozco, CHAR tiene un soporte menor de caracteres que VARCHAR (CHAR tiene un maximo de 255 caracteres).

En SqlServer el soporte es mayor.

http://msdn.microsoft.com/es-es/library/ms175055.aspx

atte.
Miguel Angel

Pegue la referencia de MySQL porque asumo que siempre sera mas creible el respaldo de lo que diga una empresa que desarrolle y produzca un motor de BD que lo que diga yo   

Gracias por la referencia aclaraste mi duda sobre la corrupcion por el tipo de campo(no menciona el motivo de la corrupcion una pena)

El motivo de la corrupcion (aunque esto es una percepcion personal propia) para mi, creo que ocurre por el hecho de que al tipo de dato varchar ser de longitud variable cuando por alguna razon no termina una transaccion realizada sobre este campo, y estamos trabajando en un motor no transaccional (por ejemplo) como todo se escribe a disco automaticamente (por el autocommit) si dicho campo de longitud variable no se completo la transaccion y como el tipo de dato es de longitud variable no esta definido en ninguna parte que se autocomplete con espacios a la derecha (como ocurriria con el tipo de datos CHAR) entonces nada... queda corrupto escrito en el datafile la informacion, y eso pues corrompe la data de la tabla en cuestion.

Generalmente tengo que creer cuando la documentacion es oficial  , sino todo se basa en "experiencias" tanto la tuya como la mia.

Para la suposicion que mencionas de la corrupcion para el campo varchar no es dable, ya que la ATOMICIDAD de una transaccion garantiza que los datos se guarden de manera correcta o no se guarden y no por partes como seria lo que supones, en caso de suceder es un problema de la transaccion mas no del tipo de dato, si un motor de base de datos no puede manejar eso es un desastre transaccionalmente hablando..

lo cual la expresion "(Varchar es muy dispuesto a corromperse no tiene mucha atomicidad)" me queda bastante confusa hasta me aventuraria a decir incorrecta

Aunque hacia referencia a los registros guardados bajo cierto tipo de datos (ya que no tiene mucha logica tener un campo con cierto tipo de dato definido y jamas insertarle datos) conclui diciendo que un campo con el tipo de dato varchar no era atomico (pero hacia referencia a su manera de manejar los registros guardados en el, mas no al tipo de dato en si porque el tipo de dato sin nada guardado no tiene mucha logica de critica) Siento mucho si por alguna u otra razon este punto se haya malinterpretado.

Obvio ya que la expresion en el contexto es incorrecta. 

atte.
Miguel Angel

[no tiene mucha atomicidad]

Referencia de MySQL:

Si usted tiene un problema con tablas que contengan filas de longitud dinámica y está utilizando únicamente columnas VARCHAR (no columnas BLOB ni TEXT), puede intentar cambiar todas las columnas VARCHAR a CHAR con ALTER TABLE. Esto fuerza a MySQL a utilizar filas de tamaño fijo. Las filas de tamaño fijo ocupan un poco más de espacio, pero son mucho más tolerantes a la corrupción.
El código de filas dinámicas actual ha sido utilizado en MySQL AB durante muchos años con muy pocos problemas, pero las filas de longitud dinámica son, por naturaleza, más propensas a errores, así que podría ser una buena idea intentar esta estrategia y ver si ayuda.

Fuente:  http://dev.mysql.com/doc/refman/5.0/es/crashing.html

Esta bien que te guste Varchar, pero por rendimiento y consistencia y evitarte problemas futuros al menos yo optaria por Char (y casi siempre lo hago).

No es que me guste, yo las utilizo no por gustos sino por necesidad.

Gracias por la referencia aclaraste mi duda sobre la corrupcion por el tipo de campo(no menciona el motivo de la corrupcion una pena), aunque trabajo con sql server y sybase debo asumir que la referencia dada por mysql es aplicable tambien a estos motores o si en estos se presentan( hasta el momento no se me han presentado ni en desarrollo, ni en deployment ni en produccion) o no hasta que no encuentre referencia que la sustente o la refute, igual no me queda claro esto

(Varchar es muy dispuesto a corromperse no tiene mucha atomicidad)

atte.
Miguel Angel

Si. estoy seguro de que clase_plantilla.php esta en la misma carpeta del documento que lo llama.
Y la funcion se llama plantilla que esta dentro de clase_plantilla.php

En esta parte estas instanciando una clase que no existe ni en el archivo que estas editando ni en el archivo clase_plantilla.php.

Código [Seleccionar] Expandir

$Contenido[]=new Plantilla("enviar_mensaje");

Pega el codigo del archivo clase_plantilla.php donde construyes la clase plantilla ya que segun el error la clase no existe en ningun lado..

atte.
Miguel Angel