Buena tarde,
Tengo problemas para almacenar en un ML, ya que
En las pruebas en Desarrollo de forma individual se hacen las pruebas y guarda bien las notas de todas las filas que correspondes a cada estudiante respectivamente.
Cuando se pasa a Producción y N Docentes en forma masiva comienzan a ingresar las notas de sus asignaturas en particuar, las notas de una fila del estudiante, pasan a otras asignaturas y otros estudiantes.
Creemos que las Relaciones se encuentran bién, por lo tanto NO nos explicamos el problema
En el cuadro en la propiedad Clave -Columnas se tiene estasi_institucion, estasi_sede, estasi_jornada, estasi_ciclo, estasi_grado, estasi_grupo, estasi_asignatura, estasi_periodo
se establece el Datos Relación como aparece en la gráfica.
el código es el siguiente en el ci-edición
function conf__form_actividades(toba_ei_formulario_ml $componente) {
$componente->set_exportar_excel();
$this->s__filtro = toba::memoria()->get_dato_instancia(‘datos_filtro’);
$parametros[‘eno_momento’] = $this->s__filtro[‘mom_id’];
$datos = $this->get_relacion()->tabla(‘estudiante_notas’)->get_filas($parametros,false, false);
$datos = rs_ordenar_por_columna ($datos, ‘per_nombre_completo’);
return $datos;
}
function evt__form_actividades__modificacion($datos) {
$this->s__filtro = toba::memoria()->get_dato_instancia(‘datos_filtro’);
foreach ($datos as $asignaturas) {
foreach ($asignaturas as $asignatura => $value) {
if ($asignatura == ‘x_dbr_clave’) $clave = $value;
}
$datos[$clave][‘eno_momento’] = $this->s__filtro[‘mom_id’];
}
$this->get_relacion()->tabla(‘estudiante_notas’)->procesar_filas($datos);
}
si ese es el caso, debe ser porque hay datos en comun que se estan mezclando… probablemente se esta usando la misma sesion, sino no deberian pisarse, ni cambiarse.
Si cada cliente tienen una sesion propia y unica, no deberia haber forma que se pisen los datos. Salvo que la carga del DR sea demasiado general y se este abarcando un grupo de datos mayor al que realmente se requiere, cada docente deberia estar trabajando con conjuntos disjuntos de datos.
function evt__form_actividades__modificacion($datos) {
$this->s__filtro = toba::memoria()->get_dato_instancia(‘datos_filtro’);
foreach ($datos as $asignaturas) {
foreach ($asignaturas as $asignatura => $value) {
if ($asignatura == ‘x_dbr_clave’) $clave = $value;
}
$datos[$clave][‘eno_momento’] = $this->s__filtro[‘mom_id’];
}
$this->get_relacion()->tabla(‘estudiante_notas’)->procesar_filas($datos);
}
Con respecto al codigo, que valores tienes en los datos del filtro que se guardan en la memoria de la instancia?, no se pueden mantener en una variable dentro del CI?.
Otro tema es la asignacion de la columna “eno_momento”, eso lo puedes realizar invocando el metodo set_columna_valor ya que es el mismo para todas las filas.
Ingeniero, gracias por responder
Los datos del filtro vienen del Ci-navegación y se recogen en el ci-edicion, corresponde al semestre que el docente elige calificar, ese semestre o momento más el id del estudiante completan la llave hija, para que se sincronise todo en masa y guardar
a raiz de un problema caótico que tuvimos en alguna ocasión y que se discutió en el foro para cargar el ML solo utilizabamos como parametro la condición ($parametr)
$datos = $this->get_relacion()->tabla(‘estudiante_notas’)->get_filas($parametros);
pero ahora solo con dicha instrucción no carga los datos al ML, y haciendo combianciones con los otros parametros logramos que muestre la carga con
$datos = $this->get_relacion()->tabla(‘estudiante_notas’)->get_filas($parametros,false, false);
es decir agregando en segundo y tercer parametro false y false respectivamente y en desarrollo almacena bien las filas probadas al azar,
Nos puedes orientar si con dichos parametros false, false, tendríamos algún problema de almacenamietno y/o cruces de información cuando se lance para el ingreso de notas en masa ?
en respuesta a tu pregunta, todo depende como cargues la relacion y paso a contarte el porque.
Los parametro extra que le pasas a la funcion get_filas, tienen el siguiente significado segun consta en la documentacion de la API.
En particular, el que te deberia interesar es el ultimo parametro, ya que es el que permite recuperar unicamente los hijos que dependen de la fila padre seleccionada, por tanto si dicho parametro esta en false, te devolvera todas las filas de la tabla, independientemente de que hayas seleccionado en la tabla padre.
Por ponerte un ejemplo:
Supongamos que cargas la relacion con los datos de una facultad para el semestre actual, un docente de Biologia selecciona su materia para asignar las notas… pero como el ultimo parametro es falso, la variable $datos… va a contener las notas de todos los estudiantes, no solamente aquellos de Biologia. Por lo tanto a medida que modifique valores, puede estar asignando correctamente los valores o pisando valores de otras materias.
Una opcion, es que el arreglo $parametros contenga mas clausulas y por tanto los datos se filtren con mayor precision… pero toda la logica de los cursores (que actuan como filtros implicitos) sigue estando anulada, con lo cual puede que recuperes mas datos de los estrictamente necesarios aun asi. La relacion es bastante sencilla, por lo que no deberias tener inconvenientes poniendo el ultimo parametro en TRUE o quitandolo directamente. Si pierdes registros al realizar dicha accion, entonces existe alguna cuestion con la operacion y la manera de trabajar de la misma, muy probablemente la carga de la relacion este filtrando de mas o de manera incorrecta.
Por ello te mencionaba al ppio, que todo dependia de como cargues la relacion… si la carga es correcta y abarca unicamente aquellos registros que se deben manipular, el resto de la operacion es lineal… si la carga es mas amplia, entonces hay que tomar ciertos recaudos al recuperar y modificar las filas, sobre todo haciendo buen uso de los cursores como ayuda, sino se pueden producir problemas como los que mencionas.
[quote author=jorozco link=topic=10576.msg46001#msg46001 date=1466195924]
Opté por traer la clave desde el ci-navegación al momento de la selección, y pegarla a los parametros de cargar el ML.
[/quote ]
no deberia ser necesario que llegues a estos extremos, no es una relacion compleja.
La opción del tercer parametro TRUE, no carga los registros en el ML, aúnque cumple todo lo que especifícas.
por lo que describis… pareciera que la tabla ‘estudiante_asignaturas’ esta manejando mas de un registro y no tiene el cursor fijado luego de realizar la carga. Lo ideal seria que dicha tabla, maneje un solo registro (para que el cursor se fije automaticamente), con lo cual el tercer parametro no te traeria inconvenientes.
Puede ser algo tan sencillo como un numero faltante en la especificacion del datos relacion… o algo tan complicado como una tabla que deberia estar dividida en varias. Eso ya es muy dependiente del proyecto y solo tu lo conoces.
