Sentencia SQL desde Delphi con Cremillas
 

Hola a Todos...

Espero que el titulo sea el adecuado, y les cuento el error que tengo

ejecuto una sentencia en el SQL Server y funciona super bien

Código SQL [-]
SELECT IDENT_CURRENT('Tarjeta') as Num

Lo que hace la sentencia anterior es asignar a Num el valor actual del Campo Identidad de una Tabla (Tarjeta)

si ejecuta la sentencia desde delphi 7, me da error, y se que son las cremillas que estan antes y despues de Tarjeta.... pero no se como ponerlas

Código Delphi [-]
Datos.AQ_Select.Close;
Datos.AQ_Select.SQL.Clear;
Datos.AQ_Select.SQL.Add('Select Ident_Current('Tarjeta') as Num');
Datos.AQ_Select.Open;

Ahora la pregunta es como declaro las Cremillas dentro de una sentencia de SQL desde Delphi...

Si le quito las cremillas si bien compila, me arroja error de ejecución...

Salu2:D:p:confused:

Código Delphi [-]
Datos.AQ_Select.SQL.Add('Select Ident_Current(''Tarjeta'') as Num');

Por cierto, son comillas, no cremillas :)

// Saludos

¿Eso se lo traga?

Yo hubiera pensado que se hacía así:

Código Delphi [-]
Datos.AQ_Select.SQL.Add('Select Ident_Current('+QuotedStr('Tarjeta')+') as Num');

Sí. En delphi, para poner una comilla dentro de una cadena de texto, se pone dos veces. Pero también como tú lo propones se puede.

// Saludos

Tnks Roman... ha... y sorry... ahora se llaman comillas.... ;):D

Yo lo he conocido como "comillas" de toda la vida, comillas simples y comillas dobles.

También yo. Ante la duda de que fuera otro modo de llamarlas, busque en la web y parece ser que cremillas es sinónimo de lo que yo conocía por diéresis.

Saludos. :)

Si parece una enfermeda diéresis parecido a diálisis, que mal suena, mejor llamar comillas simples o dobles, no os parece.

Un saludo.

En el diccionario no viene cremilla, ni en ningún sitio que he mirado.

Lo digo porque mi base de datos no se traga las comillas dobles en las instrucciones, tienen que ser simples.

Por cierto... ¿cremilla no es eso que nos echamos para el sol en la playa? :p

Si, para evitar el sol, tan bonito que tenemos en españa.

Es que cremillas ni siquiera es sinónimo de comillas dobles o simples. Es sinónimo de diéresis (¨), como la utilizada en la letra u de la palabra pingüino.

Saludos. :)

Las comillas son las comillas (', ", «, »...) y la diéresis es la diéresis (¨ -> ü). Dos cosas muy diferentes.

Las palabras que "suenan mal" son aquellas que se leen con prejuicios y las que se escriben con descuido. :)

Por favor, si teneis un tema distinto del original deberiais de crear un hilo nuevo, ¿habéis leido ya la guía de estilo? :p:D

Cierto :)
Pues entonces, otra forma:

Código Delphi [-]
Datos.AQ_Select.SQL.Add('Select Ident_Current('+#39+'Tarjeta'+#39+') as Num');

Como yo lo puse no son comillas dobles sino dos comillas sencillas juntas. Cuando el compilador ve eso, pone una sólo comilla (necesita las dos sólo para saber que dicha comilla forma parte del texto y no es el delimitador de éste), de manera que lo que llega al servidor es una comilla sencilla.

Por otra parte es raro que no acepte comillas dobles, ¿qué servidor es?

// Saludos

ElevateDB, una base de datos de la empresa que creó las dbisam, me gusta, pero según lo que estoy viendo por aquí si hubiera andado por este foro hace unos años de forma habitual lo hubiera montado todo con Firebird. Ya la cosa tiene mal apaño.

Saludos

En el error cargas la penitencia... :rolleyes:

// Saludos

Bueno, ahora que no se vende un pimiento y tengo tiempo igual me pongo poquito a poco a convertir todo a Firebird. Estimo que en un par de años puedo tener ya una versión beta. :p

Pues si usa sql estandar (más o menos), la conversión puede ser rápida :)

lo que si os aseguro es que:

1.- Que me equivoque de nombre... si se que son comillas, pero tuve un lapsus, asi que aún no se por que le puse Cremillas...

2.- la funcion 1 de Roman me funciono super.... poner 2 comillas simples juntas me sirvio.

Salu2:p:D

Si, aunque basicamente tengo dos problemas:

1-Los triggers habría que rehacerlos totalmente porque el lenguaje cambia de forma radical y el problema no es desarrollarlos, es la depuración posterior.
2-El problema inicial era que la aplicación, al venir de usar bases de datos de escritorio está plagada de ttables por lo cual habría que buscar componentes de acceso a firebird que los contemplen, cosa que ya he hecho pero tendría que probar bien.

La verdad es que antes de cambiar todo el desarrollo a esta base de datos contraté a un supuesto "guru" de delphi para que me cambiara los componentes a firebird, cosa que se hizo (bajo un presupuesto a mi parecer excesivo). El problema es que se usaron los componentes dbexpress (quiero recordar) para los ttable y como imagino que sabréis estos componentes lo primero que hacen es un select * de la tabla y con tablas grandes el programa se hacía inoperativo. Cuando le comento el tema a mi "guru" la respuesta fue "esto no es renault ocasión, no hay milagros". Por otro lado cuando trincó la pasta se "olvidó" de rematar el tema y empezaron los problemas así que opté por pasar de todo y cambiarlo yo personalmente a ElevateDB que tiene componentes propios y no me resultó excesivamente complicado hacer la migración.

La ignorancia, algo después andando por aquí me di cuenta de que hay componentes de acceso a firebird a montones y muchos de ellos, sin importarme que fueran de pago tienen componentes ttable para el acceso a las tablas.

Saludos

Bueno, si necesitas un TTable, sólo tienes que usar un TIBDataSet y poner "select * from laTabla", ya tienes un TTable, que eso es lo que hacen todos, como ya sabes.

Ya, pero eso con tablas a partir de unos miles de registros no es operativo porque tardaría muchisimo en abrir la tabla, con la base de datos que yo uso la apertura de componentes ttable es inmediato independientemente del número de registros y quiero recordar que pasado esa historia estuve haciendo pruebas con algún componente de pago para firebird y también abrían los ttable de forma inmediata, pero ya era tarde.

uummm... creo que no :D

Abrir la tabla debe ser inmediato con todos, lo que ocurre es que algunos componentes tienen una propiedad para indicar si quieres que cargue todo en memoria o no.
Evidentemente, si tiene que cargarlos todos, por ejemplo, haciendo un 'fetch' (ir al final .last) o contar los registros, será lento cuando tengas muchos registros.
Pero todos trabajan igual, me explico, un componente Table es lo que he comentado antes, un Dataset que su sql pone "select * from tabla". No hay más, ni puede haberlo.
En este hilo se habló sobre ese tema y aquí están los resultados:

Zeos:

Código Delphi [-]
procedure TZAbstractTable.SetTableName(const Value: string);  
begin    
  if FTableName <> Value then    
  begin      
    FTableName := Value;      
    if Value <> '' then        
      SQL.Text := Format('SELECT * FROM %s', [FTableName])      
    else SQL.Text := '';
  end;
end;

IBX:

Código Delphi [-]
SQL := TStringList.Create;
   SQL.Text := 'select ' + {do not localize}
    QuoteIdentifier(DataBase.SQLDialect, FTableName) + '.*, ' {do not localize}
    + 'RDB$DB_KEY as IBX_INTERNAL_DBKEY from ' {do not localize}
    + QuoteIdentifier(DataBase.SQLDialect, FTableName);
  if Filtered and (Filter <> '') then
  begin
    SQL.Text := SQL.Text + ' where ' + Filter; {do not localize}
    bWhereClausePresent := True;

MDO:

Código Delphi [-]
SQL := TStringList.Create;
  SQL.Text := 'select ' + {do not localize}
    QuoteIdentifier(DataBase.SQLDialect, FTableName) + '.*, ' {do not localize}
    + 'RDB$DB_KEY as IBX_INTERNAL_DBKEY from ' {do not localize}
    + QuoteIdentifier(DataBase.SQLDialect, FTableName);
  if Filtered and (Filter <> '') then
  begin
    SQL.Text := SQL.Text + ' where ' + Filter; {do not localize}
    bWhereClausePresent := True;

IBDAC

Código Delphi [-]
select count(*) from table;
select * from table;

Pues con la base de datos que yo uso el tema de los ttable funciona exactamente igual que con bases de datos dbf, abres el ttable y directamente puedes pedir un recordcount, irte al final, etc de forma inmediata ya tenga uno o millones de registros. No sé, igual estoy confundido en algo pero funciona de esa forma.

Sí, bueno, para irte al final rápidamente puede tener, por ejemplo, un índice descendente. Pero de todas formas, salvo que sea una tabla muuuy grande y con muuuchos campos, será rápido siempre.
Y, por supuesto, un Ttable es un dataset con un "select *".
Otra cosa que se me ocurre en tu caso es que esa base de datos use técnicas de bases de datos de escritorio, que almacena el tamaño de cada registro y multiplica por la posición del registro que quieres ir y accede directamente a esa posición en la tabla. Pero en ese caso no usaría registros de longitud variable.
En fin, aunque he usado bases de datos dbisam, no conozco elevatedb.

Bueno, la verdad es que no sé cómo van las tripas de estas cosas. Lo único que pude comprobar es que con las pruebas que hacía con firebird tardaba bastantes segundos en abrir una tabla de algunos miles de registros y eso me hizo desistir de esa vía, sin embargo con esto es todo igual que con los dbf.

Claro, es que es muy diferente usar unos componentes u otros, no es lo mismo zeos que fibplus, la diferencia en velocidad es bastante significativa.
Pero, de todas formas, ahora mismo yo aplicaría el famoso: "si funciona, no lo toques". Es lo mejor :)

Si, y además es de cómodo.... :)

Y con el día que hace hoy, apetece más bajar al puerto y sentarse al solecito a mirar el mar :)

..... o las churris... :D

:) :p :) :p