Cita:
Iniciado por gnzsoloyo 
Algunas preguntas importantes:
- ¿Se realizó algún cambio de configuración al servidor donde se encuentra la base de datos, en los días previos a cuando comenzaran los problemas?
- ¿Las query se usan por parametrización, o se construyen como cadenas de texto?
- Según informas, realizaste un debuggeo detallado. ¿Qué obtuviste en el paso previo a enviar la query a ejecutar, en cuanto a datos que iban a viajar con esa llamada?
- ¿Se realizaron verificaciones insertando y verificando los datos manualmente a la base en cuestión? ¿Qué resultados se pudieron apreciar?
- ¿Realizaste pruebas con un escenario idéntico, es decir, con iguales nombres de personas con y sin acentos, y con y sin eñes?
Buenas preguntas, aquí van mis respuestas:
- ¿Se realizó algún cambio de configuración al servidor donde se encuentra la base de datos, en los días previos a cuando comenzaran los problemas? Rpta.: No trabajo en dicha oficina, estoy haciendo
outsourcing, pero tengo entendido que llevaron la computadora que usan de servidor (no dedicado) a la oficina central de la organización para la cual trabajan, esto fue para actualizar el antivirus que usan pues no cuentan con una conexión a internet. Esto último se debió a que muchas personas en esa oficina, colocan sus dispositivos USB en esa estación de trabajo para entregar archivos de texto y aparentemente, el ordenador sufrió una infección a consecuencia de esto. Les he sugerido muchas veces que creen una red de trabajo, pero parece ser que por temas burocráticos, no se ha concretado. En un momento llegué a imaginar que se puedan haber dañado archivos del sistema por una infección, incluyendo a los archivos de la BD, pero eso no pasa de ser una especulación.
- ¿Las query se usan por parametrización, o se construyen como cadenas de texto? Rpta.: No, no he parametrizado las query, se que es una forma segura de trabajar, pero cuando hice ese módulo (el del guardado de datos en la BD), no conocía sobre eso; debo confesar que en ese entonces, me confié por las validaciones que hice del lado del cliente, ahora se realizar validaciones del lado del servidor, pero he estado ocupado con otros proyectos y no me ha alcanzado el tiempo para actualizarlo, además de que me confié porque antes de dejar de prestarle atención a este proyecto, lo dejé funcionando sin problemas. Las construyo como cadenas de texto de la forma
INSERT INTO tabla (campos) VALUES (valores).
- Según informas, realizaste un debuggeo detallado. ¿Qué obtuviste en el paso previo a enviar la query a ejecutar, en cuanto a datos que iban a viajar con esa llamada? Rpta.: Antes de ejecutar el query, lo deshabilito e imprimo la cadena con la función
var_dump() (aunque también lo he hecho directamente con
echo), la cual solamente corroboraba que los datos eran correctos. Por otro lado, ya que uso la función Ajax de jQuery, me fijé con el debugger de Chrome y Firebug de Firefox cuál era la data serializada que se transfería en cada petición asíncrona, con lo que obtenía, nuevamente, el resultado esperado, por ejemplo:
data: nombre=Juan Sánchez Vega&edad=28&ocupacion=Abogado
No se si hayan otras formas de verificar los datos, ya intenté con mensajes de alerta de JavaScript, impresiones de datos con PHP, inserción directa en la BD con código Transact-SQL y el resultado siempre es el esperado, por eso me desconcierta este problema. Si conoces otras formas, te agradeceré mucho que las menciones, siempre es bueno aprender algo nuevo cada día.
- ¿Se realizaron verificaciones insertando y verificando los datos manualmente a la base en cuestión? ¿Qué resultados se pudieron apreciar? Rpta.: Como te contesté en el último párrafo del punto anterior, realicé inserciones de manera directa (manual) a la BD con phpMyadmin y dichas inserciones siempre fueron exitosas.
- ¿Realizaste pruebas con un escenario idéntico, es decir, con iguales nombres de personas con y sin acentos, y con y sin eñes? Rpta.: Así es, por el mismo hecho de que hay nombres que llevan vocales tildadas y/o letras Ñ y otros no, hice varias pruebas con distintos nombres antes de poner en marcha la aplicación, incluso hace poco que fui a la oficina para ver ese problema, yo mismo ingresé los datos de un formulario real (de los que ellos usan), con un nombre que tuviera estos caracteres y la inserción de datos fue exitosa, la verifiqué tanto en la BD como en el listado de datos y módulo de edición de la aplicación y todo estaba bien.
Como te dije, el problema es sólo con algunos datos, por ejemplo (datos aproximados), de las más de 5000 fichas ingresadas, 850 tienen nombres con vocales tildadas y/o letras Ñ y de esas 850, hay 200 con el problema del acortamiento del nombre (únicamente del nombre, pues el campo "domicilio" también lleva vocales tildadas y no se presentaron problemas) y todo esto se presentó hace poco tiempo, no menos de 2 semanas, mientras que la implementación de Ajax tiene ya más de 2 meses. Lo curioso es que los datos que tienen este problema fueron ingresados en diversas fechas y no son consecutivos, por ejemplo, hay catorce que fue digitados en Junio, mientras que hay trentaiocho del mes de Julio pero en distintos días, otros veinticuatro de Agosto y así sucesivamente.
Dudo mucho que hayan realizado a propósito estos cambios de manera manual pues serían los propios digitadores los que perderían ya que son ellos los que tendrán que corregirlos.
Ahora, la pregunta del millón es: ¿Qué pudo haber sucedido?
