OT: Campo UI en Maria DB / Mysql

[diegod...@gmail.com]

Hola, otra vez

Estoy navegando google para encontrar el equivalente al campo UNIQUEIDENTIFIER, en MariaDB y Mysql, sin suerte.

Según lo que se sugiere, se trata de un campo del tipo Binary (16) con la función en Valor Predeterminado:

Uuid()

O bien

Select uuid()

O bien

Newid()

.....pero al agregar nuevas filas desde el SGBD, siempre carga el mismo valor. Ejemplo en mi caso:

0x73656C65637420757569642829000000

¿Alguien sabe qué es lo que estoy haciendo mal?

Muchas gracias, saludos


-----Mensaje original-----
De: diegod...@gmail.com [mailto:diegod...@gmail.com]
Enviado el: jueves, 29 de diciembre de 2016 10:53 a. m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Re: FoxyDB VS. SQLDATA

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de German Fabrcio Valdez Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Re: FoxyDB VS. SQLDATA

microsoft no discontinuo el ADO (WDAC), por supuesto que le hace propaganda al ADO.NET

y esta atada la continuidad de ADO, al ciclo de vida del windows

windows 10 muere en 2025

de todas formas yo hago sqldata (ado) y sqldata2 (odbc) ambas mediante cursoradapter

y permiten conexion continua al server mientras esta ejecutandose el programa , o abriendo y cerrando la conexion segun se necesite, en ambas clases automaticamente

lamentablemente desde visual foxpro, no me deja conectarme a AZURE de Microsoft

tambien estan optimizados los bloqueos de registro y las transacciones


El 29/12/2016 a las 0:04, 'mpulla' via Comunidad de Visual Foxpro en Español escribió:
> Hola isg-alexa.
>
> No he probado ninguna de las dos, pero he escuchado que las dos son
> buenas.
>
> Mi recomendación es que aprendas que aprendas t-sql, el standar te
> sirve en casi todos los SGDB, pero es mejor aprovechar el potencial
> del SGDB, personalmente manejo Sql Server y Postgresql (la mayoría
> trato de resolver en SGDB con SP o Funciones), no me limito a DML
> standar trato de aprovechar las características que tienes cada uno,
> ganas en velocidad y las cosas son más fáciles, te menciono unas pocas
> para que veas si existen en MariaDB
>
> CTE, CTE Recusrivas, Cross Apply (Sql Server), Lateral Join
> (Postgresql), Merger (Sql Server), Funciones de ventana Lag, Lead,
> Row_Number, Last_value, First_Value, entre otras, toda ellas muy buenas.
>
> Hay momentos en que deseamos pasar un cursor de VFP a Sql Server o
> Postgresql en un solo paso puedes apoyarte en XML o JSON (tengo
> entendido que en Sql Server 2016 JSON ya es nativo o por lo menos un
> mayor soporte)
>
>
> Sobre CursorAdapter es muy potente, lo utilizo con ODBC y es muy
> rápido, utilizo la misma tecnica que muchos abro la conexión,
> consulto, cierro la conexión, manipulo los datos, abro la conexión
> grabo y cierro sin problemas, tengo una clase que me ayuda a crearlas
> al vuelo, No te metas con ADO M$ lo descontinuo
>
> La cosa más importante es cambiar la mentalidad de hacer las cosas
> registro por registros o dentro de un while o scan, piensa en conjunto
> de datos, Sql Server y Postgresql manejan el concepto de cursores, te
> verías tentado a usarlo ya que es muy parecido a recorrer un cursor en
> un scan o while, pero hay un dicho "El mejor cursor es el que no se usa"
>
>
> Como dice Antonio ten presente un uso adecuado de las transacciones.
>
> Hay muchas cosas nuevas que tenemos que aprender y apoyo no va a
> faltar
>
> Saludos.
> Mauricio

[Antonio Meza]

Con FoxyDb tiene una función para obtener el UUID

? odb.uuid()

saludos

Antonio Meza

[Germán Fabricio Valdez]

el canpo UI se utiliza para la replicacion de sql server y para obtener el ID insertado
en la sqldata para traer el id insertado se usa la funcion REFRESH() sobre el registro o los registros insertados
en caso de que refresh no te traiga el ID tenes que agregar un campo UI char(38)
y generar el campo UI con osqdata.psqlcampoui() ,luego traes el id inserado con psqlcampoid()

si refresh te trae el ID del registro insertado no necesitas colocar la columna UI

[diegod...@gmail.com]

Gracias, Antonio!

[diegod...@gmail.com]

Gracias,  German!

 

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Germán Fabricio Valdez
Enviado el: jueves, 29 de diciembre de 2016 3:15 p. m.
Para: Comunidad de Visual Foxpro en Español <publice...@googlegroups.com>
Asunto: [vfp] Re: OT: Campo UI en Maria DB / Mysql

 

el canpo UI se utiliza para la replicacion de sql server y para obtener el ID insertado

[Víctor Hugo Espínola Domínguez]

Puedes crear un UUID propio en VFP
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Si además quieres tener un seguimiento de auditoria de los cambios, puedes usar algo como
NTOM( VAL( STRTRAN( SYS( 2007, SYS( 0 ) ) + STR( VAL( SYS( 1 ) ) - 2450000, 5, 0 ) + STR( SECONDS( ), 9, 4 ), " ", "0" ) ) )

Esto permite guardar en 8 bytes (lo que ocupa un campo tipo currency), el lugar y el usuario que hicieron el cambio, más la fecha, la hora hasta milisegundos.

Queda con una distribucción

QQQQQFFFFFSSSS.MMMM

Donde Q son hasta 5 dígitos del hash de SYS(2007) sobre SYS(0), de esta manera, te es facil tener una tablita donde se combinen los nombres de las máquinas de la red y los usuarios, con lo que puedes saber quien y donde modificaron los datos.

F es un número que sumando 2450000, te da la fecha en formato juliano (que puedes retrotraer a fecha normal). S y M son los segundos y milésimas desde media noche, por lo que puedes recuperar exactamente cuando se modificó el registro.

O sea que al insertar o modificar el registro, sobre el campo correspondiente, guardas este valor.

Además, lo utilizo como identificador unívoco en una red, puedo ir insertando registros desde distintas máquinas (aùn el mismo usuario) o en la máquina, con diferentes usuarios y la probabilidad de superposición de claves, puede darse solo si le mismo usuario en la misma máquina, corre un proceso bach que genere un grán número de registros, con una candencia superior a 1 por milisegundo.

De esa manera, aunque se generen en máquinas separadas de la red, puedo luego agregarlos, sin que se efecte la unicidad de indices.

Este es interesante desde el punto de vista de auditoria, ya que me permite saber quien, donde y cuando creó el registro y si guardo el dato en otro campo al modificar, tengo el rastro de quien, donde y cuando lo modifico.

No lo separo del checksum que indique previamente, porque el checksum, además de detectar que se cambiaron los datos, puede detectar si se cambiaron por fuera de la aplicación.

Aún en un SGBD que permite rápidos autoincrementales, veo más conveniente el uso del modelo que indico.

Uds dirán, porque no usar campos por separado, mi respuesta es, si entran con una aplicación "foranea" y ven el dato, les será muy dificil "pisar" el dato correctamente.

Posteado por Carlos Miguel Farías el 9/9/13
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Saludos,

Víctor.

Lambaré - Paraguay.

El 29 de diciembre de 2016, 11:30, <diegod...@gmail.com> escribió:

Hola, otra vez

        Estoy navegando google para encontrar el equivalente al campo UNIQUEIDENTIFIER, en MariaDB y Mysql, sin suerte.

Según lo que se sugiere, se trata de un campo del tipo Binary (16) con la función en Valor Predeterminado:

Uuid()

O bien

Select uuid()

O bien

Newid()

.....pero al agregar nuevas filas desde el SGBD, siempre carga el mismo valor. Ejemplo en mi caso:

0x73656C65637420757569642829000000

¿Alguien sabe qué es lo que estoy haciendo mal?

Muchas gracias, saludos


-----Mensaje original-----
De: diegod...@gmail.com [mailto:diegod...@gmail.com]
Enviado el: jueves, 29 de diciembre de 2016 10:53 a. m.

Para: publicesvfoxpro@googlegroups.com

Asunto: RE: [vfp] Re: FoxyDB VS. SQLDATA

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----

De: publicesvfoxpro@googlegroups.com [mailto:publicesvfoxpro@googlegroups.com] En nombre de German Fabrcio Valdez Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.
Para: publicesvfoxpro@googlegroups.com

[almonts ( www.ontarioxb.es )]

En Mysql Mariadb el campo UUID(). Es un campo caracter de 36 posiciones.

[diegod...@gmail.com]

Gracias, Victor y Carlos

 

                               ¿Ustedes usan este mismo campo UI como llave primaria, en reemplazo de ID autoincremental?

Se me ocurre que quizás no sea efectivo en performance para cláusulas where y búsquedas, pero sería una solución para muchos de los problemas de gestión de datos.

 

Gracias,

Diego

PD:  En ese escenario, de todos modos existiría la columna ID autoincremental, pero sin el atributo de primary key. Es decir, no a los efectos, entre otros, de vincular tablas cabecera-contenido.

 

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Víctor Hugo Espínola Domínguez

Enviado el: jueves, 29 de diciembre de 2016 4:17 p. m.
Para: publice...@googlegroups.com

Para: publice...@googlegroups.com

Asunto: RE: [vfp] Re: FoxyDB VS. SQLDATA

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de German Fabrcio Valdez Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.
Para: publice...@googlegroups.com

[Víctor Hugo Espínola Domínguez]

La elección del tipo de dato para la PK de una tabla depende de varios factores y de ´preferencias personales, por ejemplo en una tabla de países no se justifica ni el autoincremental ni el UUID, es preferible uno de los códigos ISO.

Saludos,

Víctor.

Lambaré - Paraguay.

Para: publicesvfoxpro@googlegroups.com

Asunto: RE: [vfp] Re: FoxyDB VS. SQLDATA

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----

De: publicesvfoxpro@googlegroups.com [mailto:publicesvfoxpro@googlegroups.com] En nombre de German Fabrcio Valdez Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.
Para: publicesvfoxpro@googlegroups.com

[German Fabrcio Valdez]

sql server maneja rangos de IDs para asignar a cada servidor distribuido, supongo que los demas motores tendran algo similar para luego mezclar los registros de todas las tablas y que no generen error

el tema es que el ID te identifica un cliente un proveedor unico en toda una red distribuida

por ejemplo anses y pami tienen numeros consecutivos que identifican a cada jubilado o pensionado en todo el pais

de argentina

del tipo bigint supongo por la longitud que tienen

asi que relacionan todo por ese numero

si usas UI para relacionar no tendrias IDs unicos en todo tu sistema distribuido por el pais

[Antonio Meza]

Cuales son para ti problemas de gestión de datos? 

Utilizar UUID depende mucho de la necesidad, mas no de lo que se lee o escucha, no puedes usar UUID simplemente porque leíste un articulo UUID vs ID y listo mejor uso los UUID, debes tener claro que acciones posteriores vas a necesitar donde los ID ya es mas problemático que beneficio.

En México la factura electrónica por ejemplo el SAT controla por medio de UUID, es decir cada factura que se genera actualmente se le asigna un UUID lo que hace que cada factura sea única sin importar quien la genero, hacer eso con campos ID es totalmente IMPOSIBLE!!! pero estamos hablando de millones de facturas generadas y que los proveedores de certificación asigna cada UUID cosa que no es en una sola maquina si no en varios servidores.

Retomando es importante conocer el alcance que tendrá el campo identificador para determinar si conviene ser un simple ID autoincrementable o un UUID.

saludos

Antonio Meza

[Antonio Meza]

Hola Victor!!

Claro que hay justificación en usar siempre campos ID autoincrementables que usar campos ISO o claves naturales, y la simple justificación es que ese valor puede cambiar y genera un problema grande.

No es un problema de preferencias personales mas bien es un problema de desconocimiento para que sirve un ID autoincrementable. que usar claves naturales como código de país, RFC, CUIT, etc.

Y UUID vs ID es dependiendo la necesidad.

Saludos

Antonio Meza

Para: publice...@googlegroups.com

Asunto: RE: [vfp] Re: FoxyDB VS. SQLDATA

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de German Fabrcio Valdez Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.
Para: publice...@googlegroups.com

[diegod...@gmail.com]

Hola, Antonio

 

                               Me refiero a problemas tales como centralizar bases de datos de datos distribuidas, o a usar replicación.

No se puede prescindir del autoincremental, pero la duda es en torno a las ventajas de usarlo como PK.

Nosotros siempre hemos usado el campo ID autoincremental como PK, y personalmente me asombró encontrar en algunos sistemas medianos (como Zeus) campos tales como CEDULA en la tabla CLIENTES definidos como PK.

 

Saludos!

[Antonio Meza]

El tema de replicacion es muy amplio al igual que bases de datos distribuidas, es cuestión de analizar las cosas!!!

Si es replicar por replicar, es decir una copia en otro servidor los Id funcionan sin problema.

Pero ya en bases de datos distribuidas la cosa cambia bastante, pero incluso se puede fácilmente usar campos ID sin caer en la trampa de dejar huecos grandes entre sucursales por dar un ejemplo pues ya estas creando una limitación en vez de una solución. 

Hace tiempo en los grandes debates filosóficos del grupo entre UUID y ID di ejemplos de base de datos distribuidas usando ID!!! jejeje

Pero usar UUID en un catalogo de Países eso si me parece una locura jajaja pues no hay miles de países ni se crean países todos los días como para justificar tal abominación jajajaj

Un mini ejemplo de bases distribuidas usando campos ID

Servidor Central: Tabla CLIENTES

id cliente RFC

1 Paco  PPP

2 Hugo HHH

Sucursal Uno: Tabla CLIENTES

id idcentral cliente RFC

10 1 Paco  PPP

12 2 Hugo  HHH

13 0   Luis  LLL

El ID = 13 de la tabla Clientes en la Surcursal UNO me dice que este cliente se registro ahí y no se tiene registro en el servidor central, entonces hay que enviar al servidor central los datos para obtener el IDCentral, una especie de replica o actualización entre la sucursal al Servidor Central.

Servidor Central: Tabla CLIENTES

id cliente rfc

5 Luis   LLL

Sucursal Uno: Tabla CLIENTES

id idcentral cliente rfc

13 5   Luis   LLL

OJO!!! Aquí las claves naturales ya toman un valor importante y es de evitar duplicidad de registros, se valida que el RFC en el servidor central no este si esta obtener su ID, si no esta insertar el registro nuevo y obtener el ID para guardarlo en la sucursal uno.

El desconocimiento general de los campos ID Autoincrementables es el gran problema,  pues solo sirven para identificar un registro de forma inequívoca, para actualizarlo y eliminarlo, para relacionar con otras tablas y si la memoria no me falla para eso nada mas, pero si lo quieres usar como un consecutivo ERROR,  para sustituir una clave natural ERROR!!! para evitar registros duplicados: ERROR!!!! para que el usuario busque por el campo ID: MEGAERROR!!! los usuarios no deben conocer los valores ID ya que son para uso exclusivo de la base de datos y del programador.

En fin es un cuento de nunca acabar jajajajaja pero por desconocimiento!!!!!

saludos

Antonio Meza

[diegod...@gmail.com]

Hola, Antonio

 

                Después de algunos días he podido retomar la tarea, pero encuentro que sistemáticamente me arroja “Fallo al actualizar la tabla” después de ejecutar:

 

louuid = odb.uuid()

 

para obtener el valor y reemplazarlo en la columna ui, char(38)

 

¿Estoy haciendo algo mal?

 

Muchas gracias,

Diego

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Antonio Meza

Enviado el: jueves, 29 de diciembre de 2016 11:58 a. m.

[Antonio Meza]

Pero que código de error o numero de error te da después del la linea louuid = odb.uuid()

Si puedes mostrar el código antes y después de esa linea.

saludos

[diegod...@gmail.com]

 

Gracias, Antoni o

 

                                El código del error es -5 && La cantidad de Campos no es igual a la cantidad de valores

 

Sólo se produce al ejecutar la función   oDb.uuid()  

He intentado evitar el uso de la función y cargar un valor arbitrario en el campo UI, y no tuve problemas.  

Intenté también correr ejecutar la función, pero no cargar su resultado, sino un valor arbitrario en el campo UI. Se produjo el error.

 

                Desde el código del sistema se actualizan los datos y finalmente se llama la siguiente función para guardar los cambios:

En ésta función, antes de actualizar, se completan algunas columnas referenciales que son homólogas en todas las tablas de la BD.

Te marco en negrita lo que considero relevante:

 

---

LPARAMETERS _otablacursorodb, _orefresca, _odevuelveID, _ogeneraotravez, _oarchivoaejecutar

 

_idlast = 0

odb_connect()

 

*_uuid010117 = oDb.uuid() && esta comentado, porque intenté correr la función y después usar la variable en replace.

 

SELECT &_otablacursorodb

 

REPLACE version WITH version + 1

REPLACE id_ABM_empresas WITH _screen._ID_ABM_EMPRESAS

REPLACE id_ABM_SUCURSAL WITH _screen._ID_ABM_SUCURSAL

REPLACE id_ABM_regiones WITH _screen._ID_ABM_REGIONES

REPLACE id_ABM_usuarios WITH _screen._ID_ABM_USUARIOS

REPLACE id_ABM_ultimo_usuario WITH _screen._ID_ABM_USUARIOS_LAST

REPLACE id_ABM_RUBRO WITH _screen._ID_ABM_RUBRO

REPLACE id_ABM_equipo WITH alltrim(sys(0))

REPLACE ui WITH oDb.uuid()   && he probado con la variables en vez de la función.

 

 

                                   *&&&&&&&&&&&&&&&&&&&&&&&&&&& GUARDAR &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

 

                                   IF oDb.CursorChanges(_otablacursorodb)

                                               IF oDb.Update(_otablacursorodb,.t.)

                                                           IF oDb.Commit() 

                                                                 IF _orefresca = .t.

                                                                       IF _odevuelveID = .f.

                                                                             oDb.Refresh(_otablacursorodb,oDb.id_Last)     

                                                                            _idlast = oDb.id_Last

                                                                       ELSE

                                                                             oDb.Refresh(_otablacursorodb)     

                                                                           _idlast = 0

                                                                       ENDIF

                                                                                                                                             

                                                                            IF _ogeneraotravez = .t.                               

 

                                                                                   &&&&&&&&  despues de hacer un refresh(), ya no se puede seguir actualizando el cursor &&&&&&&&&&&&&&&&&

                                                                                  IF oDb.CursorClose(_otablacursorodb)                                                            

 

                                                                                        &_oarchivoaejecutar 

 

                                                                                        IF oDb.CursorOpen(_otablacursorodb)

                                                                                              IF oDb.CursorEdit(_otablacursorodb)

                                                                                              ELSE

                                                                                                    ODB_commit_errores(4, _otablacursorodb) 

                                                                                                    RETURN     

                                                                                              ENDIF

                                                                                        ELSE

                                                                                              ODB_commit_errores(5, _otablacursorodb) 

                                                                                              RETURN

                                                                                        ENDIF

                                                                                  ELSE

                                                                                        ODB_commit_errores(6, _otablacursorodb) 

                                                                                  ENDIF

                                                                                  &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

 

                                                                            ENDIF                                                                                                                                        

                                                                 ENDIF

                                                           ELSE

                                                                       oDb.Rollback()                                                              

                                                                       ODB_commit_errores(1,  _otablacursorodb, ALLTRIM(STR(oDb.error_Code)))

                                                                       _idlast = 0

                                                           ENDIF

                                               ELSE

                                                           ODB_commit_errores(2, _otablacursorodb, ALLTRIM(STR(oDb.error_Code)))  && 2 No se pudo actualizar la tabla

                                                           _idlast = 0

                                               ENDIF

                                    ELSE                              

                                         ODB_commit_errores(3, _otablacursorodb, ALLTRIM(STR(oDb.error_Code)))  && 3 No se detectan cambios en la tabla

                                   ENDIF                                                                                                                                                                                                        

RETURN _idlast

[Antonio Meza]

Pero el error que comentas -5 && La cantidad de Campos no es igual a la cantidad de valores esta en la función CODE() estas usando antes esta función?

saludos

Antonio Meza

[diegod...@gmail.com]

Mis disculpas.  Se trata de “Update()”

 

__transactionError                 = -5        && Error al iniciar una transacción

 

Grave error, pero sigo sin saber cómo evitarlo.

 

Gracias, saludos

[Antonio Meza]

Si no usas odb.uuid() el update funciona bien?

Es decir si llamas a la funcion uuid() el update ya no funciona? porque entonces parece ser un problema de transacciones. puedes confirmar?

saludos

Antonio Meza

[diegod...@gmail.com]

Hola, Antonio

 

Justamente es de las primeras pruebas que hice:

Si no llamo a la función odb.uuid(), el update funciona bien.

 

Gracias, saludos

[Antonio Meza]

perfecto deja reviso como esta aplicando la transacción el uuid() 

[Antonio Meza]

Algo estas haciendo antes porque ya hice pruebas y no me afecta obtener el UUID() ni antes ni después del update()

saludos

Antonio Meza

[German Fabricio Valdez]

puede ser el tipo de datos del campo ui, me parece que no es char(38)

char(38) es la sqldata.dll

[Antonio Meza]

El valor devuelto es de 36 caracteres!!!

Pero el error esta en la transacción al preparar la transacción, alguna instrucción tiene antes!!

saludos

[diegod...@gmail.com]

Antonio:

 

Yo ejecuto la función antes del update(), para poder colocar ese valor en la columna UI.

La realidad es que si vos no tenés problemas al hacerlo, supongo que tengo que volver a revisar todo y seguir probando.

 

German:

 

Gracias. He visto en google que algunos indican tipo binario, y algunos hablan de varchar 36 para MySQL y MariaDB.  He probado todas las opciones posibles, pero de todas maneras, el problema me surge al ejecutar odb.uuid() de FoxyDB.

Seguramente se trata de algún defecto en mi entorno, pero hice incluso la prueba más categórica:

 

1)      Le quite el campo UI a la tabla

2)      Antes del UPDATE(), ejecuté odb.uuid(),unas líneas más arriba, sin darle utilidad al resultado

3)      En UPDATE() se genera el error y no actualiza la tabla

 

NOTA:  si no ejecuto odb.uuid(), los cambios se guardan sin problemas.

 

Saludos!

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Antonio Meza
Enviado el: viernes, 6 de enero de 2017 3:51 p. m.
Para: Comunidad de Visual Foxpro en Español <publice...@googlegroups.com>
Asunto: Re: [vfp] Re: OT: Campo UI en Maria DB / Mysql

 

Algo estas haciendo antes porque ya hice pruebas y no me afecta obtener el UUID() ni antes ni después del update()

[Antonio Meza]

El error que te indica FoxyDb es de transacción, posiblemente hay una transacción de solo lectura activa que no se ha confirmado y por eso no se puede iniciar la transacción de lectura y escritura para ejecutar el Update.

Por eso pensé que al obtener el UUID() se estaba quedando la transacción sin confirmar, pero no tuve ese problema al modificar un registros, obtener el uuid y mandar a guardar.

Algo mas debes estar haciendo por ahi. jejeje

saludos

Antonio Meza