MySql

[ignacio]

Carlos,
> Si tienes el valor disponible es que ya existe, sino no podrías fiarte.
> Hará un 'append blank' para obtener el valor o algo así, y luego
> modificará el registro, pero no existe forma de anticipar ese valor en el
> cliente sin haberlo insertado antes.
ADO no inserta nada cuando haces un AddNew(). El proceso de grabación se
realiza directamente en el método Update().
En el caso de SQLServer tienes la variable [email=@@INDENTITY]@@INDENTITY[/email] para conocer la
última indentidad creada, osea, tan sencillo como
oDataSource:QueyValue( "SELECT [email=@@IDENTITY]@@IDENTITY[/email] AS 'LastInsertId'" )
> AddNew() ya recupera un ID, es porque ha hecho un insert blank o similar.
> Eso es fácil de demostrar: Usanod dos clientes, en una hago un AddNew,
> luego lo hago en el otro cliente, y en el crimero hago un cancel. Que
> sucede con el ID no usado?
José Luis, comenta que después de AddNew() el valor de la identidad ya esta
disponible. Yo no lo he probado, pero efectivamente, si es así puede haber
saltos como tu comentas. ¿Pero a quien le preocupan esos saltos? A mi no
desluego. De hecho actualmente ya no se utilizan contadores numéricos para
identificar filass sino más bien identificadores tipo GUID de 16 bytes.
Saludos
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Carlos Mora" <carlos.mora@atisa.es> escribió en el mensaje
news:45224182$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Ignacio,
>
>>> A que te refieres con 'tener disponible'? Seguramente al hacer un select
>>> * mrecibo todo, pero nada me asegura que el último es el que yo inserté.
>>> Por eso existe en MySQL el LastInsertId().
>>
>> SQLServer en mi opinión lo hace de una forma mucho más elegante ya que es
>> completamente automático, y no hay necesidad de recuperar nada a través
>> de una función. Este misma problema lo tiene FireBird con los
>> 'Generators'.
>> Lo que comenta José Luis, es que en el momento que haces un
>> oRecordSet:AddNew(). En ese mismo momento ya puedes interrogar por el
>> valor del campo incremental y te da su valor. No hay nada más que hacer.
>
> Si tienes el valor disponible es que ya existe, sino no podrías fiarte.
> Hará un 'append blank' para obtener el valor o algo así, y luego
> modificará el registro, pero no existe forma de anticipar ese valor en el
> cliente sin haberlo insertado antes.
>
>> En el caso de FireBird y supongo que también MySQL tienes que llamar a la
>> función que te da el número del contador y a continuación lo incrementea
>> en 1, y luego dicho número eres tu el responsable de guardarlo en el
>> campo en cuestion. Por lo tanto es un sistema bastante manual, y además
>> no te garantiza que tu número sea el último, sino simplemente, te
>> garantiza que tu número es único, pues el siguiente que llame a la
>> función le van a devolver el siguiente número, y es probable que el otro
>> usuario realice el alta antes que tu.
>
> FireBird es totalmente diferente de MySQL, MySQL gestiona internamente los
> autoincrementales.
> No es necesario tener un ID que sea último, necesito que sea único, y se
> genera al insertar el registro. Puede ser que el cliente ADO gestione la
> recuperación del ID, es probable. Lo unico que te puedo garantizar es que
> para que un ID sea realmente un ID tiene que existir, por lo que si
> AddNew() ya recupera un ID, es porque ha hecho un insert blank o similar.
> Eso es fácil de demostrar: Usanod dos clientes, en una hago un AddNew,
> luego lo hago en el otro cliente, y en el crimero hago un cancel. Que
> sucede con el ID no usado?
>
>> Toda esta complejidad desaparece en cualquier caso para cualquier BD
>> cuando se utilizan con ADO.
>
> Es probable, ya aprenderé un poco más al respecto.
>
> Un saludo,
>
> Carlos

[Carlos Mora]

Ignacio Ortiz de Zúñiga escribió:
> Carlos,
>
>> Si tienes el valor disponible es que ya existe, sino no podrí­as fiarte.
>> Hará un 'append blank' para obtener el valor o algo así­, y luego
>> modificará el registro, pero no existe forma de anticipar ese valor en el
>> cliente sin haberlo insertado antes.
>
> ADO no inserta nada cuando haces un AddNew(). El proceso de grabación se
> realiza directamente en el método Update().
> En el caso de SQLServer tienes la variable [email=@@INDENTITY]@@INDENTITY[/email] para conocer la
> última indentidad creada, osea, tan sencillo como
>
> oDataSource:QueyValue( "SELECT [email=@@IDENTITY]@@IDENTITY[/email] AS 'LastInsertId'" )
Claro, seguramente existí­a esa función, pues el cliente ADO o lo que
esté accediendo SOLO PUEDE CONCER ESE VALOR DESPUES del update()
>> AddNew() ya recupera un ID, es porque ha hecho un insert blank o similar.
>> Eso es fácil de demostrar: Usanod dos clientes, en una hago un AddNew,
>> luego lo hago en el otro cliente, y en el crimero hago un cancel. Que
>> sucede con el ID no usado?
>
> José Luis, comenta que después de AddNew() el valor de la identidad ya esta
> disponible. Yo no lo he probado, pero efectivamente, si es así­ puede haber
> saltos como tu comentas. ¿Pero a quien le preocupan esos saltos? A mi no
> desluego. De hecho actualmente ya no se utilizan contadores numéricos para
> identificar filass sino más bien identificadores tipo GUID de 16 bytes.
Si despues del AddNew ya conoce el ID de la fila SIN HABERLA INSERTADO,
entonces a SQL Server lo programó Harry Potter porque sabe de antemano
que nadie ha insertado un registro durante el periodo que hiciste
AddNew() y el Update(), lo cual es realmente envidiable.
Yo creo que es pura lógica.
Saludos

[jose.luis]

Ignacio,
Solo una puntualización,
>
> José Luis, comenta que después de AddNew() el valor de la identidad ya
> esta disponible. Yo no lo he probado, pero efectivamente, si es así puede
> haber saltos como tu comentas. ¿Pero a quien le preocupan esos saltos? A
> mi no desluego. De hecho actualmente ya no se utilizan contadores
> numéricos para identificar filass sino más bien identificadores tipo GUID
> de 16 bytes.
>
Yo he comentado que después del Insert que está disponible el valor del
autoincremental. Como muy bien has explicado, en ADO el insert se hace
después del Update, no antes.
Este código explica el funcionamiento en ADO de los autoincrementales
/* Tabla SqlServer
CREATE TABLE MiTabla (
[CONTADOR] [int] IDENTITY (1, 1) NOT NULL ,
[CCODALM] [varchar] (3) NOT NULL ,
[NSTOCK] [numeric](15, 5) NULL
)
*/
Local oRs
oRs := CreateObject("ADODB.Recordset")
oRs:Open("SELECT * FROM MiTabla",'Cadena de conexion....",adUseServer,
adOptimisticLock)
oRs:Properties("Update Resync") = adResyncUpdates
oRs:AddNew()
oRs:ccodalm := "WWW"
oRs:nStock := 90
oRs:Update()
? oRs:Contador // --_> el que haya sido asignado
oRs:Close()
Saludos,
José Luis Capel

[Carlos Mora]

José Luis,
>> José Luis, comenta que después de AddNew() el valor de la identidad ya
>> esta disponible. Yo no lo he probado, pero efectivamente, si es así­ puede
>> haber saltos como tu comentas. ¿Pero a quien le preocupan esos saltos? A
>> mi no desluego. De hecho actualmente ya no se utilizan contadores
>> numéricos para identificar filass sino más bien identificadores tipo GUID
>> de 16 bytes.
>>
>
> Yo he comentado que después del Insert que está disponible el valor del
> autoincremental. Como muy bien has explicado, en ADO el insert se hace
> después del Update, no antes.
Menos mal! Si además de aprender SQL tení­a que aprender futurologí­a ya
me estaba buscando local para ponerme un chiringuito y dedicarme a algo
más entretenido
Un saludo,
Carlos

[ignacio]

José Luis,
Entiendo, se conoce el valor después del Update y no antes. Entonces te
habia entendido mal. Perdona.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"José Luis Capel" <jose.luis@iaicom.com> escribió en el mensaje
news:45226ea9$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Ignacio,
>
> Solo una puntualización,
>
>>
>> José Luis, comenta que después de AddNew() el valor de la identidad ya
>> esta disponible. Yo no lo he probado, pero efectivamente, si es así puede
>> haber saltos como tu comentas. ¿Pero a quien le preocupan esos saltos? A
>> mi no desluego. De hecho actualmente ya no se utilizan contadores
>> numéricos para identificar filass sino más bien identificadores tipo GUID
>> de 16 bytes.
>>
>
> Yo he comentado que después del Insert que está disponible el valor del
> autoincremental. Como muy bien has explicado, en ADO el insert se hace
> después del Update, no antes.
>
> Este código explica el funcionamiento en ADO de los autoincrementales
>
> /* Tabla SqlServer
> CREATE TABLE MiTabla (
> [CONTADOR] [int] IDENTITY (1, 1) NOT NULL ,
> [CCODALM] [varchar] (3) NOT NULL ,
> [NSTOCK] [numeric](15, 5) NULL
> )
>
> */
>
> Local oRs
>
> oRs := CreateObject("ADODB.Recordset")
> oRs:Open("SELECT * FROM MiTabla",'Cadena de conexion....",adUseServer,
> adOptimisticLock)
> oRs:Properties("Update Resync") = adResyncUpdates
> oRs:AddNew()
> oRs:ccodalm := "WWW"
> oRs:nStock := 90
> oRs:Update()
> ? oRs:Contador // --_> el que haya sido asignado
> oRs:Close()
>
> Saludos,
> José Luis Capel
>
>
>
>

[Manu]

Ignacio, te digo sinceramente que en ningún momento he pretendido atacar
a Xailer... en mi frase que tu resaltas:
De Manu: [De cualquier modo en un 75% nos podremos conformar con lo que
proporciona Xailer.]
Sustituye Xailer por Delphi, VB o si quieres Condor1... y quiero decirte
que para mí­ eso es un porcentaje muy alto partiendo de la base que para
hacer el DataSet y el DataSource se están usando sentencias muy
generales y atendiendo a SQL estandar...
A partir de aquí­ puedes pensar lo que quieras... yo no solamente apoyo a
Xailer si no que lo he recomendado en más de una ocasión y me consta que
lo han adquirido por esa misma recomendación...
Yo si creo que tengo que intervenir en una conversación hasta el final
sobre todo cuando de ella se aprende. Y cualquier cosa que se diga
seguro que irá en beneficio de todos...
Saludos
Ignacio Ortiz de Zúñiga escribió:
> Carlos,
>
>> Primero, creo que la discusión se ha desviado. Lo que entiendo que es la
>> opinión de Manu y que comparto, es que no se puede usar SQL genérico, que
>> es diferente según el motor que uses.
>
> La comparto igualmente, pero no puedo compartir que para sacar partido de un
> motor SQL al 100% haya que usar un cliente nativo.
>
>> Creo que esa idea de que alguien ha atacado a Xailer (¡Sacrí­lego, a la
>> puta hoguera!)
>
> De Manu: [De cualquier modo en un 75% nos podremos conformar con lo que
> proporciona Xailer.]
>
> Está escrito unos mensajes más arriba. Yo no me invento nada. Si alquien
> ataca a nuestro producto exigo demostraciones o disculpas. Lo que prefiera.
>
>> y no tiene sentido discutirlo.
>
> Tienes toda la razón. Yo por mi parte abandono este hilo definitivamente.
>
> Un saludo,
>

[Manu]

Ignacio parce que te lo tomas como crí­ticas destructivas y no lo son, o
al menos, yo no las tomo como tales...
De todo lo expuesto pienso que más o menos todos podemos aprender algo
pero no puedo permitir que se digan cosas que no son ciertas porque
pueden inducir a confusiones y de eso, lo que más me duele es que digas
públicamente que me "mandaste todo el ODBC", si es así­ a mí­ no me
llegó... te repito que yo vi tu código durante unos minutos contigo en
la reunión del GO2000 en Sevilla y tú viets el mí­o en ese mismo monento,
y tu comentario fue "no soportas unicode" ( y a partir de ahí­ me puse a
currármelo ). Te repito lo que sí­ me enviaste fue los dataset y
datasources de las DBF y apartir de ese momento le mandé a Jose posibles
mejoras para acelerar algunos procesos y el rendimiento. Y Jose me pasó
contigo y estubimos hablando por correo de mi propuesta de usar el
sistema de mensajes de Windows y lo refresh de los controles para hacer
eso y no te parecieron oportunas. En la reunión del GO2000 te dije que
si querí­as algo que estuviera en mi poder podrí­as contar con ello y me
consta que tu harí­as lo mismo conmigo. De eso es lo que yo tengo
constacia. Esa es la aclaración que quiero hacer.
Ahora en cuanto al resto, creo que la gente si puede aprender... yo ya
hice ejemplos con todos los gestores de ODBC que cayeron en mis manos
(MySQL, Interbase, MS, etc) y con todas las LIB que pude incluyendo la
de Xailer y Condor1... por eso sé que hay problemas. Borland lo intentó
solucionar precisamente eliminando el BDE y creando los DbExpess y digo
"LOS" porque DbExpress es una definición relamente, hay un gestor
DbExpress para cada gestor de bases de datos... de hecho antes existí­a
un concepto que eran los SQL Link que hací­an los propios fabricantes de
bases de datos o la propia Borland. Esto SQL Link incluso podí­an
saltarse el BDE como por ejemplo el de Interbase de Borlanad o Apolo
para DBF... Y eso es lo que yo hice en Condor1... cree una clase llamada
TODBCVTable que serí­a la clase virtual y un arbol con la jerarquí­a de
Condor1 más o menos así­:
TODBCVTable -> Genérica
TODBCTable -> Estandar
TODBCTbAccess -> solo para Access
TODBCTbFirebird -> solo Firebird
TODBCTbSQLServer -> solo SQLServer
etc, etc
Fue así­ como solucioné las incompatibilidades entres los driver ODBC...
lógicamente para que no hubiera problemas todos tení­an los mismos
métodos y datas (polimorfismo y herencia)hací­a que pudieras parametrizar
los programas y evitar la recompilación de los programas. Y si fuera
inevitable sólo tener que cambiar la funcion de la clase:
oQuery := TODBCTbAccess()
o
oQuery := TODBCTbSQLServer()
y luego to igual
oQuery:New()
oQuery:GoTo( n ) por ejemplo
Otra cosa dices:
//------
Eso no es cierto. Sólo en el caso de ODBC es necesario que exista una clave
primaria. Y se ha hecho para asegurar la integridad de los datos, es decir,
por seguridad. No me habrí­a costado nada haber hecho un UPDATE a lo bestia,
pero no me parece seguro.
//------
A eso me refiero a ODBC, es la unica que accede a bases de datos, vamos
a llamarlas SQL para diferenciarla de DBF...
Porqué hay que ser ta proteccionista del programador!!! y si por un
motivo inexplicable, si quieres, no hay claves únicas? me tengo que
olvidar de hacer un mantenimiento con Xailer?
Otra cosa:
A estas alturas sí­ sé lo que es "conversión y casting" pero lógicamente
a eso no me referí­a... lo mismo que sé que si quieres tratar cualquier
valor desde xHarbour y C tienes que pasar por el ITEM.
Saludos
Ignacio Ortiz escribió:
> Manu,
>
> Perdoname, pero has entrado tu en polemica diciendo claramenete que Xailer
> no es capaz de hacer el 25% de operaciones que se pueden hacer con un motor
> SQL, Releete a ti mismo por favor.
>
> Y me reafirmo cualquier base de datos
>> que diseñemos para un programa concreto estará mal implementa desde el
>> principio aunque funcione inicialmente tarde o temprano habrí­a que hacer
>> remiendos más o menos costosos en tiempo, trabajo y por supuesto en
>> dinero...
>
> Las BD se diseñan con los adminitradores que incluyen las mismas y no existe
> ninguna necesidad de pensar que con que libreria se le va atacar. Vale para
> cualquiera. Eso es absurdo.
>
>> De ahí­ que yo dijera que para eso estaban los dataset y datasources de por
>> ejemplo, Xailer... para las reglas "más o menos básicas" esto está
>> perfecto... pero cuando te quieres meter en profundidad y además en
>> velocidad tienes que usar accesos directo al cliente quieras o no... de
>
> Y el ejemplo.
>
>> ahí­ que pusiera un ejemplo real de mi trabajo... y quieras o no esto hace
>> que cada vez que cambies la base de datos tengas que hacer modificaciones
>> en tu programa
>
> Si te refieres a la ubicación de la BD tan sólo hay que cambiar el dato
> cConnect del Datasource.
>
>> alias que son administradas desde el gestor que accede al BDE o Borland
>> DataBase engine (antiguamente IDEAPI)
>
> Hace mucho que Borland abandono el BDE me temo.
>
>> con el sólo cambiar el Alias para que apunte a otro gestor de BBDD ya
>> pirula perfectamente... tengo unos añitos de experiencia en este sentido y
>> para nada es tan fácil como eso simplemente... hemos pasado por Access,
>> INGRES, Interbase y ahora por Oracle.
>
> Y que tiene que ver eso con que Xailer no pueda acometer el 25% o más de
> operaciones con un motor SQL
>
>> Tanto el ejemplo que me pides como del 25% que yo he calculado "por
>> encima", posiblemente será más, lo tendrás diariamente cuando nuestros
>> compañeros y sin embargo amigos tengan aplicaciones funcionando y decidan
>> un dí­a cambiar de SQLServer a Oracle por ejemplo, o hacer algo como lo que
>> indica José Luis...
>
> Estas mezclando churras con merinas. Una cosa es que no sea sencillo pasar
> de un gestor BD a otro y otra cosa muy distinta es que Xailer no sea capaz
> de exprimir a ambos al 100%
>
>> Por otro lado, cuando he mencionado los cuellos de botella como por
>> ejemplo la conversión de tipos de datos, te aseguro que para mí­ ha sido lo
>> más dificil de resolver para que esto no fuera un retardo. Es cierto que
>> en una reunión del GO2000 me mostraste como lo hací­as tú y yo te mostré
>> como lo hací­a yo
>
> Jamas me enseñaste tu codigo, y tampoco hice yo nada por verlo.
>
>> tú el mí­o... hubo un momento en que pedí­ información más detallada de los
>> dataset y datasources y muy gentilmente me mandaste los referidos a DBF
>> para usarlo como modelo...
>
> Se te mando el ODBC completo.
>
>> De lo que recuerdo de aquel dí­a sí­ tenias que hacer conversiones, lo
>> primero es que las bases de datos tienen más tipos de datos que C, y este,
>> a su vez, más que xBase y por supuesto lo que devuelve ODBC lo tienes que
>> pasar al tipo de xBase o sea a una variable... o sea a un ITEM...
>> A diferencia de como yo he implementado Condor1 y Eagle1 que no llevan
>> bucle de conversión...
>
> xHarbour, que no Xailer, sólo entiende de HB_ITEMS. Es imposible no
> utilizarlos, al final, tarde o temprano utilizas el HB_ITEM quieras o no. Y
> en cuanto a la conversión te diré que en absoluto. Hay que distinguir entre
> conversión y casting, y te aseguro que no es lo mismo.
>
>> José Alfonso que vino a mi casa pudo observar la diferencia de tiempo del
>> mismo programa usando Condor1 y usando otras clases... él habló en la
>> entrevista que le hicieron en Radio CresWin de unas 70 veces más rápido.
>
> Quien ha hablado de velocidad. No he sido yo. No se si serás más rápido que
> Xailer, seguramente si, pero te aseguro que la velocidad con que muestre
> Xailer actualmente los datos no es nada despreciable. Más que suficiente.
>
>> Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
>> para hacer un EDIT o un borrado ya que me imagino que para fabricar el
>> WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
>> crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
>
> Eso no es cierto. Sólo en el caso de ODBC es necesario que exista una clave
> primaria. Y se ha hecho para asegurar la integridad de los datos, es decir,
> por seguridad. No me habrí­a costado nada haber hecho un UPDATE a lo bestia,
> pero no me parece seguro.
>
>> por hacer una comparativa la clase TODBCTable que serí­a la equivalente a
>> Xailer no tiene esa restricciones.
>
> Entonces tendrá problemas de seguridad porque no podrás asegurar que un
> UPDATE sólo afecta a una fila.
>
>> Otro ejemplo para decirte que hay veces que las generalidades no
>> funcionan. Una tabla de access con un tipo de datos Datetime y que además
>> este campo sea el campo de clave única para que se puedan hacer los edit y
>> deletes con Xailer, por lógica te fallará... pruébalo y luego te digo
>> porqué... si te falla, claro.
>
> Pruebalo tu primero, y me haces el ejemplo. Te recuerdo que Xailer en ODBC
> es capaz de manejar los campos dateteime como cadenas y por tanto no se
> pierde información de la hora.
>
>> o cuando uses los tipos TEXT de algunas BBDD o BLOB o unicode... intenta
>> hacer insert o updates estandar con eso y verás que no es tan fácil... con
>> algo muy generalista.
>
> Precisamente toda esa complejidad es la que te esconden motores como ODBC o
> ADO.
>
>> En todo momento quiero que nos tomemos esto como una crí­tica constructiva
>> y no para crear polémicas... pienso que es una manera de que todos
>> aprendamos un poco más cada dí­a y crezcamos como programadores.
>
> Por supuesto que no.
>
> Un saludo,
>
>
>

[Manu]

José Luis una cosa es el SELECT y otra lo que hay en la tabla, porqué te
quedas en ese WHERE?
José Luis Capel escribió:
> Manu,
>
> Siento curiosidad de saber como haces esto:
>
>> Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
>> para hacer un EDIT o un borrado ya que me imagino que para fabricar el
>> WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
>> crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
>> por hacer una comparativa la clase TODBCTable que serí­a la equivalente a
>> Xailer no tiene esa restricciones.
>
> Imagí­nate que necesitas traerte estos datos:
>
> SELECT Apellido FROM MiTabla WHERE Apellido = 'Capel'
>
> Esa tabla te devuelve 2 registros (yo y mi hijo).
>
> Modifico uno de los registros y actualizo la base de datos.
>
> ¿Que ocurre? ¿Como haces esto?
>
> Antes que me digas nada... esto es una muy mala práctica de programación
> Sql. Solo te lo pongo como ejemplo que tiene difí­cil solución (o no
> tiene).
>
> Saludos,
> José Luis Capel
> PD: en ADO es posible que te modifique tooodos los registros cuyo apellido
> sea 'Capel' (no lo he probado).

[jose.luis]

Manu,
Te propongo un pequeño ejercicio.
Suponiendo estas dos tablas de una base de datos
TABLA CAB_ALBARANES
Campo Tipo Len PK
Numero Int Si
Serie Char 2 Si
Nombre Char 30
BaseImp Numeric 10,2
CuotaIv Numeric 10,2
Total Numeric 10,2
TABLA LIN_ALBARANES
Campo Tipo Len PK
Numero Int Si
Serie Char 2 Si
Linea Int Si
Arti Char 30
Precio Numeric 10,2
Cant Numeric 10,2
Y mediante cualquier sistema que nos proveea de un conjunto de datos
actualizables (ADO, Xailer/Datasets, Condor1, Eagle 1) hacemos este select:
oRs:Open("SELECT A.Serie, A.Numero, B.Arti, B.Precio, B.Cant, (B.Precio *
B.Cant) AS Subtotal FROM LIN_ALBARANES B INNER JOIN CAB_ALBARANES A ON
A.numero = B.numero AND A.serie = B.Serie WHERE A.Serie = '06' ORDER BY
Subtotal")
Y seguimos con este código:
oRs:GoTop()
oRs:Edit()
oRs:Precio = 23.10
oRs:Update()
¿Como se deberí­a de resolver esta situación? ¿Hay posibilidad de actualizar
con éxito esa linea? ¿Que tiene que hacer el sistema de acceso a datos?
¿Que hará el motor de la base de datos?
Damos por sentado que:
A. no hay problemas de concurrencia.
B. no han sido modificados por otro terminal o transacción los datos en la
base de datos.
Voy a mirar en ADO y Sql Server como resuelven esta situación...
Espero vuestros comentarios!!
Saludos,
José Luis Capel

Manu wrote:
> José Luis una cosa es el SELECT y otra lo que hay en la tabla, porqué te
> quedas en ese WHERE?
>
> José Luis Capel escribió:
>> Manu,
>>
>> Siento curiosidad de saber como haces esto:
>>
>>> Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
>>> para hacer un EDIT o un borrado ya que me imagino que para fabricar el
>>> WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
>>> crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
>>> por hacer una comparativa la clase TODBCTable que serí­a la equivalente a
>>> Xailer no tiene esa restricciones.
>>
>> Imagí­nate que necesitas traerte estos datos:
>>
>> SELECT Apellido FROM MiTabla WHERE Apellido = 'Capel'
>>
>> Esa tabla te devuelve 2 registros (yo y mi hijo).
>>
>> Modifico uno de los registros y actualizo la base de datos.
>>
>> ¿Que ocurre? ¿Como haces esto?
>>
>> Antes que me digas nada... esto es una muy mala práctica de programación
>> Sql. Solo te lo pongo como ejemplo que tiene difí­cil solución (o no
>> tiene).
>>
>> Saludos,
>> José Luis Capel
>> PD: en ADO es posible que te modifique tooodos los registros cuyo
>> apellido sea 'Capel' (no lo he probado).

[jasm]

Paco,
Idependientemente de que motor de bases de datos te decidas a usar y de
las discusiones que se han planteado en este hilo, lo que debes hacer, y
es muy importante, es aprender SQL. Después, si quieres usar
datasources/datasets, accesos nativos a motores de datos, ADO, ODBC o
cualquier otra cosa es a nivel aplicación.
Por otra parte, la elección del motor de bases de datos a usar vendrá
determinado por las necesidades de la aplicación y sobre todo por el
cliente que contrate tus servicios o compre tu software.
Desde ya te aclaro que llegar a hacer un programa que no requiera
modificaciones en las sentencias SQL al realizar un cambio de motor de
bases de datos es bastante complicado, además de requerir un gran
conocimiento de todos los motores existentes.
Personalmente me he decidido por MySQL, ¿por que? Sencillamente por que
permite el sistema embebido y puedo distribuir aplicaciones que se
ejecutan de forma local sin necesidad de instalar el servidor. Es
importante cuando vendes programas que se han de instalar los clientes
sin ninguna ayuda. A parte de eso, posteriormente, pasar del sistema
local al sistema cliente/servidor es tan fácil como copiar la base de
datos local al directorio del servidor, cambiar la configuración en el
programa y ponerlo a funcionar.
Mi consejo:
1.- Aprender bien SQL estándar.
2.- Aprender bien SQL aplicado a cada motor (incluyendo sistema de
programacion de transacciones, procedimientos almacenados, funciones de
usuario, etc). Al menos dos/tres sistemas: MySQL, SQL Server y Oracle.
3.- Si vas a hacer una aplicación y quieres que soporte los tres
sistemas, estudiar muy bien las diferencias para poder implementarlas.
4.- Aprender a usar datacontrols/datasets.
5.- Aprender a usar otras cosas como Eagle 1 o Condor 1.
6.- Aprender como funciona ADO, ODBC y los accesos nativos.
Y, aunque soy un enamorado de SQL Server desde hace años, me gusta usar
MySQL por ser fácil de instalar (instalar y salir funcionando sin más
mareos), permitir el embebido (como apuntaba antes) y por que hay más
servidores en internet usando MySQL que SQL Server (y puedes usarlos
para alojar bases de datos y acceder a ellos desde cualquier sitio).
Un saludo y buena travesí­a por el SQL,
José Alfonso Suárez Moreno

[Manu]

La verdad es que no se como lo hace ADO pero si haces un RecordSet de
mas de una tabla se supone que no es actualizable... en Delphi puedes
decirle que es request live pero tienes que indicar al programa qué
tiene que hacer en un insert, update y delete...
José Luis Capel escribió:
> Manu,
>
> Te propongo un pequeño ejercicio.
>
> Suponiendo estas dos tablas de una base de datos
>
> TABLA CAB_ALBARANES
> Campo Tipo Len PK
> Numero Int Si
> Serie Char 2 Si
> Nombre Char 30
> BaseImp Numeric 10,2
> CuotaIv Numeric 10,2
> Total Numeric 10,2
>
> TABLA LIN_ALBARANES
> Campo Tipo Len PK
> Numero Int Si
> Serie Char 2 Si
> Linea Int Si
> Arti Char 30
> Precio Numeric 10,2
> Cant Numeric 10,2
>
> Y mediante cualquier sistema que nos proveea de un conjunto de datos
> actualizables (ADO, Xailer/Datasets, Condor1, Eagle 1) hacemos este select:
>
> oRs:Open("SELECT A.Serie, A.Numero, B.Arti, B.Precio, B.Cant, (B.Precio *
> B.Cant) AS Subtotal FROM LIN_ALBARANES B INNER JOIN CAB_ALBARANES A ON
> A.numero = B.numero AND A.serie = B.Serie WHERE A.Serie = '06' ORDER BY
> Subtotal")
>
> Y seguimos con este código:
>
> oRs:GoTop()
> oRs:Edit()
> oRs:Precio = 23.10
> oRs:Update()
>
> ¿Como se deberí­a de resolver esta situación? ¿Hay posibilidad de actualizar
> con éxito esa linea? ¿Que tiene que hacer el sistema de acceso a datos?
> ¿Que hará el motor de la base de datos?
>
> Damos por sentado que:
>
> A. no hay problemas de concurrencia.
> B. no han sido modificados por otro terminal o transacción los datos en la
> base de datos.
>
> Voy a mirar en ADO y Sql Server como resuelven esta situación...
>
> Espero vuestros comentarios!!
>
> Saludos,
> José Luis Capel
>
>
> Manu wrote:
>
>> José Luis una cosa es el SELECT y otra lo que hay en la tabla, porqué te
>> quedas en ese WHERE?
>>
>> José Luis Capel escribió:
>>> Manu,
>>>
>>> Siento curiosidad de saber como haces esto:
>>>
>>>> Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
>>>> para hacer un EDIT o un borrado ya que me imagino que para fabricar el
>>>> WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
>>>> crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
>>>> por hacer una comparativa la clase TODBCTable que serí­a la equivalente a
>>>> Xailer no tiene esa restricciones.
>>> Imagí­nate que necesitas traerte estos datos:
>>>
>>> SELECT Apellido FROM MiTabla WHERE Apellido = 'Capel'
>>>
>>> Esa tabla te devuelve 2 registros (yo y mi hijo).
>>>
>>> Modifico uno de los registros y actualizo la base de datos.
>>>
>>> ¿Que ocurre? ¿Como haces esto?
>>>
>>> Antes que me digas nada... esto es una muy mala práctica de programación
>>> Sql. Solo te lo pongo como ejemplo que tiene difí­cil solución (o no
>>> tiene).
>>>
>>> Saludos,
>>> José Luis Capel
>>> PD: en ADO es posible que te modifique tooodos los registros cuyo
>>> apellido sea 'Capel' (no lo he probado).
>

[Carlos Mora]

José Luis Capel escribió:
> Carlos,
>
>>> Creo que podrí­as hacer o bien un SELECT LAST o un SELECT MAX.
>> No. Lo insertado no es necesariamente el último, considerando inserts
>> concurrentes podrí­a ocacionar que te retorne la fila que insertó el otro
>> proceso.
>
> Pues no se me ocurre ahora mismo otra forma de consultarlo.. Normalmente
> los autoincrementales son valores numéricos positivos o negativos (esto ya
> se sabe antes de hacer el select). Entonces el último disponible es el
> LAST/MAX que hagas en la consulta. Si en ese momento hay 7 terminales
> haciendo inserts... ¿que tiene que hacer el motor de base de datos: esperar
> a que terminen todos los inserts para darte a ti la información correcta? ¿Y
> si hay 4 más en cola? La idea del autoincremental es que tu no te tengas
> que preocupar de cual es el último, de eso ya se encarga el motor de base de
> datos. Por lo tanto, el valor devuelto en el SELECT LAST/MAX es válido para
> el momento justo de la consulta.
LastInsertID() da un valor DIFERENTE PARA CADA CONEXION, VALIDO SOLO
DESPUES DE UN INSERT. Si tu haces un insert con ID digamos 1001 e
inmediatamente otra estacion hace otro, al consultar lastinsertid DESDE
TU CONEXION devolverá el valor 1001, y 1002 para la otra. La razon de
existir del Lastinsertid() (o como se llame la funcion en la BBDD que
uses)no es otra que esa.
>>>> Una pregunta: Como sabes cual es el ID de un INSERT con clave
>>>> autoincremental en SQL Server?
>>> Después de hacer el INSERT ya tienes disponible el valor del
>>> autoincremental
>>> (por lo menos en ADO).
>> A que te refieres con 'tener disponible'? Seguramente al hacer un select *
>> mrecibo todo, pero nada me asegura que el último es el que yo inserté. Por
>> eso existe en MySQL el LastInsertId().
>>
>
> Con Ado, si tienes establecida la propiedad del recordset "Update Resync" a
> adResyncAutoIncrement, cada actualización de registro (si es un insert) te
> devuelve el valor del autoincremental.
Exacto, no tengo dudas de eso. Actualiza el registro en vivo y en
directo y lo hace en forma correcta. Creo que nos desviamos del tema ya
que la discusion era que yo decia que no podias saber el ID hasta
despues del update, nada más, y eso era porque en algún momento Ignacio
malinterpretó algún comentario tuyo donde entendí­a que despues del
AddNew() ya conocí­as el ID. Nada más.
Saludos

[Carlos Mora]

José Luis,
Perdón por la intromisión.
> Te propongo un pequeño ejercicio.
> Y mediante cualquier sistema que nos proveea de un conjunto de datos
> actualizables (ADO, Xailer/Datasets, Condor1, Eagle 1) hacemos este select:
>
> oRs:Open("")
>
> Y seguimos con este código:
>
> oRs:GoTop()
> oRs:Edit()
> oRs:Precio = 23.10
> oRs:Update()
>
> ¿Como se deberí­a de resolver esta situación? ¿Hay posibilidad de actualizar
> con éxito esa linea? ¿Que tiene que hacer el sistema de acceso a datos?
> ¿Que hará el motor de la base de datos?
> Damos por sentado que:
>
> A. no hay problemas de concurrencia.
> B. no han sido modificados por otro terminal o transacción los datos en la
> base de datos.
>
> Voy a mirar en ADO y Sql Server como resuelven esta situación...
Interesante. Cambiarí­a el SELECT a
SELECT
A.Nombre, A.Serie, A.Numero, B.Arti, B.Precio, B.Cant, (B.Precio *
B.Cant) AS Subtotal FROM LIN_ALBARANES B INNER JOIN CAB_ALBARANES A ON
A.numero = B.numero AND A.serie = B.Serie WHERE A.Serie = '06'
ORDER BY Subtotal
Para complicar más el asunto, ya que solo aparecen la PK de A en las
columnas. Y si fuera posible, quitarí­a del select A.serie y A.numero.
Carlos

[Thefull]

Jose luis,
Pero es que NO se diseña las bases de datos.
El primer paso ANTES del diseño de las bases de datos, es el modelo
conceptual.
Teniendo el modelo conceptual, de poco importa el modelo fí­sico.
Por ejemplo, bajo Rational Rose, puedes diseñar el modelo E/R, y decir
para que motor de bases de datos lo quieres.
Saludos
Rafa Carmona

[jose.luis]

Rafa,
>
> Pero es que NO se diseña las bases de datos.
>
> El primer paso ANTES del diseño de las bases de datos, es el modelo
> conceptual.
>
> Teniendo el modelo conceptual, de poco importa el modelo físico.
> Por ejemplo, bajo Rational Rose, puedes diseñar el modelo E/R, y decir
> para que motor de bases de datos lo quieres.
>
> Saludos
> Rafa Carmona
>
Pero... ese Rational Rose (que no se lo que es)... se encarga de 'batallar'
con los diferentes motores??
Saludos,
José Luis Capel
www.capelblog.com
www.mundoxbase.info

[jasm]

José Luis,
Existen muchí­simas herramientas CASE para el diseño y modelado de bases
de datos. Todas son herramientas que asisten al diseño de la base de
datos, ninguna es para nada una "caja mágica" en la que pulsando tres
botones se crea una base de datos y toda su lógica de negocio.
Las que conozco conectan a través de ODBC, ADO o de forma directa con el
motor de bases de datos, crean la base de datos, generan las tablas y
gran parte de la lógica de negocio de la base de datos (hay cosas que no
hacen, como consultas almacenadas, funciones de usuario ... ).
Supongo que a lo que se refiere Rafa es que en esas herramientas se
parte del modelo conceptual o abstracto de una base de datos que se va
modelando para, finalmente, obtener un fichero de texto con las
sentencias SQL que generarán la base de datos dependiendo del motor a
usar (este fichero de texto no se ve la mayorí­a de las veces ya que
pulsando un botón se realiza la conexión y la generación de la base de
datos de un tirón).
DBDesigner4 o SyBase son herramientas CASE para estas cosas.
En cuanto al tema de una aplicación que pueda soportar varios motores de
bases de datos, es decir, que programes para después alojar tu base de
datos en SQL Server, Oracle, MySQL, etc. es una utopí­a perseguida por
casi todos los programadores, de forma que para compatibilizar el código
de las consultas tienes que crear una capa "traductora" entre las
distintos motores, dejar de usar una buena cantidad de funciones del
servidor y por supuesto se hace muy difí­cil de mantener y utilizar
disparadores, consultas almacenadas, funciones de usuario, etc.
programadas en el servidor por total incompatibilidad (al final tienes
que meter la logica de negocio de la base de datos en la aplicación
rompiendo la independencia e integridad de los datos).
Saludos
Jose A. Suárez

[jose.luis]

José Alfonso,
Entonces, por lo que entiendo, esas herramientas CASE están fuera del tema
de discusión. Si es la herramienta la que va a hacer nuestro trabajo de
implementación del modelo abstracto entonces, no hay mucho más que hablar.
Vamos... esa es al menos mi opinión.
Saludos,
José Luis Capel
www.capelblog.com
www.mundoxbase.info
"José Alfonso Suárez Moreno" <jasm@tpvsoft.com> escribió en el mensaje
news:454baff9$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> José Luis,
>
> Existen muchísimas herramientas CASE para el diseño y modelado de bases
> de datos. Todas son herramientas que asisten al diseño de la base de
> datos, ninguna es para nada una "caja mágica" en la que pulsando tres
> botones se crea una base de datos y toda su lógica de negocio.
>
> Las que conozco conectan a través de ODBC, ADO o de forma directa con el
> motor de bases de datos, crean la base de datos, generan las tablas y
> gran parte de la lógica de negocio de la base de datos (hay cosas que no
> hacen, como consultas almacenadas, funciones de usuario ... ).
>
> Supongo que a lo que se refiere Rafa es que en esas herramientas se
> parte del modelo conceptual o abstracto de una base de datos que se va
> modelando para, finalmente, obtener un fichero de texto con las
> sentencias SQL que generarán la base de datos dependiendo del motor a
> usar (este fichero de texto no se ve la mayoría de las veces ya que
> pulsando un botón se realiza la conexión y la generación de la base de
> datos de un tirón).
>
> DBDesigner4 o SyBase son herramientas CASE para estas cosas.
>
> En cuanto al tema de una aplicación que pueda soportar varios motores de
> bases de datos, es decir, que programes para después alojar tu base de
> datos en SQL Server, Oracle, MySQL, etc. es una utopía perseguida por
> casi todos los programadores, de forma que para compatibilizar el código
> de las consultas tienes que crear una capa "traductora" entre las
> distintos motores, dejar de usar una buena cantidad de funciones del
> servidor y por supuesto se hace muy difícil de mantener y utilizar
> disparadores, consultas almacenadas, funciones de usuario, etc.
> programadas en el servidor por total incompatibilidad (al final tienes
> que meter la logica de negocio de la base de datos en la aplicación
> rompiendo la independencia e integridad de los datos).
>
>
> Saludos
>
> Jose A. Suárez

[jasm]

Jose Luis,
Obviamente lo has entendido al revés.
Saludos
Jose A. Suarez

[jose.luis]

José Alfonso,
>
> Obviamente lo has entendido al revés.
>
¿Donde me he perdido ? :-S
Saludos,
José Luis Capel
www.capelblog.com
www.mundoxbase.info

[jasm]

Las herramientas CASE no definen por tí­ el modelo abstracto.

[Thefull]

José Alfonso Suárez Moreno escribió:
> Las herramientas CASE no definen por tí­ el modelo abstracto.
sasto! poco mas que decir...
Saludos
Rafa Carmona

[jose.luis]

José Alfonso,
> Las herramientas CASE no definen por tí el modelo abstracto.
Yo no he dicho que definan, sino que implementen!!!
Saludos,
José Luis Capel

[Thefull]

José Luis Capel escribió:
> José Alfonso,
>
>> Las herramientas CASE no definen por tí­ el modelo abstracto.
>
> Yo no he dicho que definan, sino que implementen!!!
Pero Jose Luis, lo que te estoy intentando explicar, es que lo ves desde el
punto de vista del modelo fí­sico, y yo te estoy diciendo, que tienes que
ver un paso antes, que es el modelo conceptual o E/R.
A partir del modelo E/R, el modelo fí­sico, es ya según el Motor que
uses, pero el conceptual, es para cualquier motor.
Quizás estamos hablando de cosas distintas, todo puede ser.. jejeje,
Saludos
Rafa Carmona

[jose.luis]

Rafa,
> Pero Jose Luis, lo que te estoy intentando explicar, es que lo ves desde
> el
> punto de vista del modelo físico, y yo te estoy diciendo, que tienes que
> ver un paso antes, que es el modelo conceptual o E/R.
>
> A partir del modelo E/R, el modelo físico, es ya según el Motor que uses,
> pero el conceptual, es para cualquier motor.
>
> Quizás estamos hablando de cosas distintas, todo puede ser.. jejeje,
>
Yo ya parto del hecho de que el modelo conceptual ya lo tienes ideado y
plasmado en papel. Entonces, para hacer la implementación de ese modelo
conceptual, en cada motor de datos que vas a utilizar se van a utilizar
necesariamente difernetes sintaxis. Además, según el sistema de acceso a
datos, deberás de adaptar el código para cada motor de datos.
Partiendo del mismo modelo conceptual, la implementación puede ser
diferente. En eso creo que todos estamos de acuerdo. ¿no?
Saludos,
José Luis Capel

[Thefull]

José Luis Capel escribió:
> Rafa,
>
>> Pero Jose Luis, lo que te estoy intentando explicar, es que lo ves desde
>> el
>> punto de vista del modelo fí­sico, y yo te estoy diciendo, que tienes que
>> ver un paso antes, que es el modelo conceptual o E/R.
>>
>> A partir del modelo E/R, el modelo fí­sico, es ya según el Motor que uses,
>> pero el conceptual, es para cualquier motor.
>>
>> Quizás estamos hablando de cosas distintas, todo puede ser.. jejeje,
>>
>
> Yo ya parto del hecho de que el modelo conceptual ya lo tienes ideado y
> plasmado en papel. Entonces, para hacer la implementación de ese modelo
> conceptual, en cada motor de datos que vas a utilizar se van a utilizar
> necesariamente difernetes sintaxis. Además, según el sistema de acceso a
> datos, deberás de adaptar el código para cada motor de datos.
>
> Partiendo del mismo modelo conceptual, la implementación puede ser
> diferente. En eso creo que todos estamos de acuerdo. ¿no?
>
Claro, y con herramientas como rational rose, o power designer, lo hace
el solito, para el motor que quieras, o los mas 'usados'.
Quizás, el problema lo vas a tener a nivel de programador de tu
aplicación GUI, en este caso con Xailer, o cualquier otro, pues tendrás
que adaptar tus sentencias según el motor seleccionado. ( o usar ADO ),
que supongo que te abstraerá todo eso, pero al usar ADO, dependes ahora
ya de un sistema operativo en concreto, y bueno, podrí­amos decir, que
estas en las mismas...
Ahora no estoy seguro, pero creo que también podrí­as crearte vistas a
traves del modelo conceptual, para el motor que quisieras, ahorrando
mucho tiempo.
Saludos
Rafa Carmona