¿BDE con Delphi 10? ¿Y con Community Edition ?

[Javierus]

Buenas :)

¿Se puede usar el BDE con la Community Edition?

Por favor, por favor, por favor, :) abstenerse de recomendar el cambio del BDE a otro sistema de a cesó a BD; lo que necesito saber ahora es si alguien ha probado el BDE sobre Delphi 10 y/o Community Edition

gracias :)

[mamcx]

Ya que no quieres escuchar que BDE, obsoleto desde como la ultima glaciaciones debido ser cambiado, pues bájate la community y miras, no.?

[Javierus]

Ya que no quieres escuchar que BDE, obsoleto desde como la ultima glaciaciones debido ser cambiado, pues bájate la community y miras, no.?

Sí, ya la estoy instalando; pero si alguien lo ha probado de verdad, quizás podría darme alguna información de primera mano.

Me explicó :)

Pretendo actualizar de Delphi 2007 a Río, y de BDE al motor SQL que más fácil me ponga la transición (tiempo de desarrollo/prestaciones DB), pero no todo a la vez

Pero he pensado que si cambio de DB primero, luego quizás tenga tenga problemas para adaptar los componentes de DB a Río, por lo que parece sensato cambiar primo el IDE sí es posible :)

[Casimiro Notevi]

Lo pienses como lo pienses, está claro que del BDE tienes que olvidarte, yo los probé en 1998 y me dije "esto no sirve para algo serio", así que imagínate hoy en día, 21 años después.

[Javierus]

Lo pienses como lo pienses, está claro que del BDE tienes que olvidarte, yo los probé en 1998 y me dije "esto no sirve para algo serio", así que imagínate hoy en día, 21 años después.

Sí, quiero cambiar a otra BD y quizás a Río, y por eso me planteo cambiar primero a Río y luego a SQL

Gracias de todos modos :)

[mamcx]

Creo que estas tomando una medida DEMASIADO conservadora. Hacer un upgrade por pasos esta bien y en general es recomendado. Pero en este caso, es una perdida total de tiempo. Un exceso de cautela!

En especial, migrar un driver de acceso a BD es de lo mas trivial que hay, máxime en Delphi donde hay una interface que todos siguen...

Hay muchas otras opciones que te permiten acceder a formatos de BD viejos, como ADO o ODBC.

----

No te digo esto por ser denso. Yo trabajo, concurrentemente, con sqlite, postgresql, mysql, SQL Server, oracle, firebird formatos de bd a base de texto inventados a "como sea". Y ademas, todo esto desde Delphi, .NET, Python, Swift, y próximamente rust. No podría contar el numero de drivers y APIs que he manejado, ADEMAS de los que hago personalmente.

Osea: Yo migro y paso todo el tiempo. Aun si es tu primera vez, no debería tomarte mas que unos cuantos días y eso, solo pensando en falta de experiencia.

En resumen: Deja BDE atras sin miedo. Hasta te diría que pasarse a Firebird (mas poder) o Sqlite (mas simple) conjuntamente no te suma gran cosa. Pasa datos a texto, rehaces estructura y carga datos. Haciendo a PELO eso toma horas. Con herramientas??? segundos.

[newtron]

Hola a tod@s.


Estando de acuerdo en que el BDE es "caca" y hay que quitarselo de encima lo antes posible también creo que, dependiendo del código del programa, el cambio a un motor de base de datos SQL puede ser bastante laborioso.


Lo digo porque las operaciones manejando tablas son distintas a las que se hacen con instrucciones SQL, p.e.:


no es lo mismo:




Tabla.edit;
Tabla.fieldbyname('CAMPO').AsString:='EJEMPLO';
Tabla.Post;



que:



...UPDATE TABLA
...SET CAMPO='EJEMPLO' WHERE...;



a no ser que consigas unos componentes para la base de datos que decidas usar que te permitan cierta compatibilidad con el código que manejes la migración puede ser bastante dura.


Yo ya pasé por esto y fue un tema complicado porque la primera intención era migrar a firebird y me encontré con ese problema, que alrededor del 40% del código que tenía no me servía. Encontré un componente que simulaba el "ttable" para firebird pero, una vez hecha la migración, me di cuenta de que lo que hacía realmente era un "SELECT * FROM..." cada vez que abría una tabla y al probarlo con cierta cantidad de datos se hacía inviable.


Igual hay alguna forma que desconozco pero no le vi una solución razonable a este tema y al final acabé por migrar a ElevateDB que si que tiene componentes "ttable" nativos y me servía casi todo el código que tenía para BDE.


Por otro lado comentarte que yo he estado usando BDE con Delphi 2007 sin grandes problemas, no sé si con 2010 será igual pero imagino que si.



Saludos

[Javierus]

Creo que estas tomando una medida DEMASIADO conservadora
migrar un driver de acceso a BD es de lo mas trivial que hay, máxime en Delphi donde hay una interface que todos siguen...


Gracias por tu aporte; pero no me parece trivial: no se usa ni una sola Query en todo el código; todo se basa en descendientes de TTable, por lo que el Locate es el estándar, y para operar sobre un subconjunto de datos, el SetRange o el FindNearest con un bucle por condición.

He probado con dos o tres conjuntos de componentes que sustituyen el TTable por una versión propia, y los resultados han sido desalentadores: desde el peaor (que la aplicación se parase un ratazo al abrir un formulario), hasta el mejor (que la aplicación fuese 10 veces más lenta)

Modificar todo el código de golpe no es una opción: Actualmente funciona, no tiene errores y tiene buen rendimiento. Cuanto más modifiques de golpe, más errores incorporarás.

Así que tengo que migrar a un conjunto de componentes que me permita mantener el paradigma de funcionamiento de TTable, y después de eso ir adaptando datamodule a datamodule

[Javierus]

Estando de acuerdo en que el BDE es "caca" y hay que quitarselo de encima lo antes posible también creo que, dependiendo del código del programa, el cambio a un motor de base de datos SQL puede ser bastante laborioso.
Lo digo porque las operaciones manejando tablas son distintas a las que se hacen con instrucciones SQL

al final acabé por migrar a ElevateDB que si que tiene componentes "ttable" nativos y me servía casi todo el código que tenía para BDE.
Eso es lo que necesito.
¿¿¿No recordarás con qué tipo de problemas te encontraste??? Eso me ayudaría muchísimo


Por otro lado comentarte que yo he estado usando BDE con Delphi 2007 sin grandes problemas
En esa situación estoy yo en este momento: terminando la migración a 2007, con un puñado de clientes ya trabajando sólo con esa versión, mientras el resto están aún con Delphi 5

Lo que no he indicado es que mi empresa tiene exclusivamente 1 aplicación, que nos da de comer desde hace 30 años (Turbo Pascal->Borland Pascal->Delphi 3->Delphi 5->Delphi 2007), y se desarrolla en ella todos los días, por lo que no se puede hacer una "parada técnica" de, p.ej., un mes

[Casimiro Notevi]

Javierus, por lo que conozco de tu caso, te diría que no le tengas miedo a cambiar a Firebird+IBX, por ejemplo, ya que pasando a SQL estarías abierto a usar otros en cualquer momento que decidas cambiar.
Conozco también el caso del compañero newtron y no es que sea mala su elección, es bastante buena (salvo que no es software libre y no se tiene acceso al fuente), pero son elecciones tomadas por diversos motivos en momentos determinados y también influenciados por motivos externos como clientes que se deben continuar asistiendo, continuidad con el código, etc.
El tema de las "TTable" es fácilmente solucionable limitando los registros cuando se conectan a ellas a ninguno o a un número determinado. Está el código fuente del mismo, por lo que no hay problema, se cambia el predeterminado "select * from tabla" por "select * from tabla limit 1" o "select * from tabla where codigo=0", etc.

De todas formas, tomes la solución que sea, aquí estaremos para intentar ayudarte.

Y, obviamente, es necesario desarrollar los cambios sin tocar lo que está funcionando, para poder seguir asistiendo a tus clientes, así que sería una "nueva rama" (o copia/pega :)) del proyecto, donde irías haciendo los cambios, para no tocar "el original". Y si se toca algo, eso se pasa al nuevo también.

[newtron]

Eso es lo que necesito.
¿¿¿No recordarás con qué tipo de problemas te encontraste??? Eso me ayudaría muchísimo



Ya lo he comentado. El principal problema es que el código del programa estaba diseñado para trabajar con objetos Ttable y ese código no funciona con bases de datos SQL. Me hice de unos componentes "Ttable" para firebird (no recuerdo el nombre) que eran totalmente compatibles con el código que tenía pero cuando hacía el "open" de la tabla para después poder operar con ella lo que internamente realmente hacía es un "SELECT * FROM..." para cargarla en memoria y después poder hacer "findkey", "edit", etc... y eso se volvía totalmente inoperativo con tablas grandes tuviendo que desechar esa vía.


Mi consejo es que si quieres conservar el código migrando a una base de datos SQL eches un vistazo a la web de ElevateDB (https://www.elevatesoft.com/products?category=edb) que te puede resolver el problema, no lo vas a hacer en un "pispas" pero es factible y te permitirá migrar a una base de datos bastante robusta y cambiando el código fuente lo mínimo. Si es cierto que tiene un coste pero, a mi forma de entender, asumible para las contrapartidas que da.



Cualquier duda me comentas.


Saludos

Edito: Se me olvidaba comentar que el costo que tiene esta base de datos no es por cada instalación de la misma, lo que se pagan son los componentes que instalas en tu Delphi siendo gratuita la instalación en los clientes del motor de base de datos.

[mamcx]

Puede que tenga la memoria desactualizada, pero el problema de la velocidad con ttables no era tan desastroso:

http://edn.embarcadero.com/article/27790

En el caso de ADO, es posible optimizar muy fácilmente la cosa. Como te digo, he usado tantos motores y lenguajes, que no veo como puedes realmente estar en un problema que haga que valga la pena seguir con BDE.

En general, si usas una solución y optienes un desempeño ABISMAL, entonces algo esta faltando. Yo use mucho ADO en Delphi y no recuerdo haber tenido problemas de desempeño. Hay algunos parámetros que hay que setear para que el componente funcione al estilo TTable...

Pero no tengo Delphi a la mano pa chequear...

[Casimiro Notevi]

Me ha extrañado mucho lo de los problemas comentados con el componente "Table" y yo no recuerdo que fuese tan malo, aunque la última vez que lo usé hace tantos años que ni me acuerdo, así que he hecho una prueba muy simple, apenas he tardado 5 minutos en escribir el proyecto y grabarlo en video.

Solamente quería comprobarme a mí mismo y de paso recordar cómo iba, porque no me gusta contar algo que esté equivocado, quería estar seguro, así que esto es lo que he hecho:

He abierto una vieja máquina virtual con windows XP y delphi 2007, he creado un nuevo proyecto.
De la pestaña Interbase (son los componentes IBX) he añadido un ibdatabase, un ibtransaction y un ibTable.
Lo he conectado a una base de datos firebird 2.5 de una gestión contable que hice hace unos años.
He puesto un dbgrid, un dbnavigator y unos botones para conectar y otro para hacer una búsqueda.
No hay nada de código SQL, ni Query, ni nada de nada, solamente el componente "table".

He añadido (con ibexpert) a una de las tablas 110.000 registros que más los que tenía, suman un total 110.053 registros.
Son poquitos, pero para hacer una prueba creo que valen, y el test lo he grabado en video.

Botón conectar es instantáneo, desconectar igualmente, vuelta a conectar al instante.
Voy al final de la tabla, casi instantáneo. Voy de nuevo al principio, instantáneo.
En el registro 100.000 la descripción es "HOLA", le doy a buscar, que usa un simple locate y se puede ver que es instantáneo.
Avanzo hacia arriba (retrocedo) un poco y edito un registro cambiando su descripción también por "HOLA", es instantáneo, la edición de cualquier registro no tarda absolutamente nada.
Voy de nuevo al principio y le doy a buscar, encuentra el registro editado también instantáneamente.
Desconectar y salir.

Aquí está el video de prueba (https://mega.nz/#!fds0AQoK!MvXIcbpfFxC0Yh0TqYDc5ms2gkQSNCMgpCMJtiSTzAU).
Y aquí está el código fuente, nada de SQL, ni nada de nada.
unit Unit6;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Grids, DBGrids, DB, IBCustomDataSet, IBTable, IBDatabase, ExtCtrls,
DBCtrls, StdCtrls;

type
TForm6 = class(TForm)
IB1: TIBDatabase;
TR1: TIBTransaction;
ibtbl1: TIBTable;
ds1: TDataSource;
dbgrd1: TDBGrid;
dbnvgr1: TDBNavigator;
pn1: TPanel;
bt2: TButton;
bt1: TButton;
ed1: TEdit;
bt3: TButton;
procedure bt1Click(Sender: TObject);
procedure bt2Click(Sender: TObject);
procedure bt3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form6: TForm6;

implementation

{$R *.dfm}

procedure TForm6.bt1Click(Sender: TObject);
begin
ib1.Connected := not(ib1.Connected);
tr1.Active := ib1.Connected;
ibtbl1.Active := ib1.Connected;
ds1.Enabled := ib1.Connected;
if not(ib1.Connected) then
bt1.Caption := 'Conectar'
else
bt1.Caption := 'Desconectar';
end;

procedure TForm6.bt2Click(Sender: TObject);
begin
close;
end;

procedure TForm6.bt3Click(Sender: TObject);
begin
ibtbl1.Locate('NOMBREPROVINCIA',ed1.Text,[]);
end;

end.

[Javierus]

Gracias por la ayuda, Casimiro
Volveré a probarlo, porque que esa prueba la hice hará tres años, y no debo de recordar bien dónde estaba el problema.

En mi caso las pruebas no deberían ser difíciles, dado que nunca utilizo el TTable directamente; usuarios uno propio heredado de TTable, por lo que bastará con encapsular en él el IBXTable. Ya tenía previsto probar el ElevateDB que me recomendó Newtron, así que probaré ambos

Gracias de nuevo a todos; ya informaré de mi experiencia

[Casimiro Notevi]

Sí, prueba el elevatedb, creo que te gustará, va bastante bien también.
Lo único, que no es libre.

[Javierus]

Comprobado: se puede instalar el paquete del BDE y funciona perfectamente
El único problema es que te tienes que buscar la vida para conseguir el paquete del BDE, porque no está en descarga libre

[Casimiro Notevi]

Está en la web de embarcadero (codecentral) para descargar, aquí (https://cc.embarcadero.com/results.aspx?keywords=bde).

[Javierus]

Está en la web de embarcadero (codecentral) para descargar, aquí (https://cc.embarcadero.com/results.aspx?keywords=bde).

Gracias, Casimiro, pero no sirve: se trata de Community Edition, así que me dice que no puedo descargar eso con mi usuario

[newtron]

...
De la pestaña Interbase (son los componentes IBX) he añadido un ibdatabase, un ibtransaction y un ibTable.

Casimiro, entonces eso es lo que me falló en su día. La persona que me hizo la migración de mis componentes a SQL y que según sus palabras era "el que más sabía de delphi de España" no conocía o no cayó en usar estos componentes y usó unos que no servían y cuando le comenté el problema que había con tablas de muchos registros me dijo textualmente "no hay milagros". Unos cuantos de miles de euros y unos cuantos meses de trabajo tirados a la basura. :mad:

De una forma o de otra estoy bastante contento con ElevateDB, hay alguna cosa que creo que con Firebird no podría hacer y que me resulta muy cómoda como el poder usar la base de datos embebida para entornos pequeños de red.

En fin..... estas cosas modernas....

[Casimiro Notevi]

Casimiro, entonces eso es lo que me falló en su día. La persona que me hizo la migración de mis componentes a SQL y que según sus palabras era "el que más sabía de delphi de España" no conocía o no cayó en usar estos componentes y usó unos que no servían y cuando le comenté el problema que había con tablas de muchos registros me dijo textualmente "no hay milagros". Unos cuantos de miles de euros y unos cuantos meses de trabajo tirados a la basura. :mad:

De una forma o de otra estoy bastante contento con ElevateDB, hay alguna cosa que creo que con Firebird no podría hacer y que me resulta muy cómoda como el poder usar la base de datos embebida para entornos pequeños de red.

En fin..... estas cosas modernas....

El problema es que "la informática" es un campo tan amplio que no se puede saber todo, algo que nos parece casi imposible resulta que alguien conoce la forma de hacerlo incluso fácil.
El "truco" con el componente Table es tener indexado el campo que se va a usar, y no olvidar traer solo los registros que se necesiten, aunque esto último también vale para cualquier consulta, sea del tipo que sea.

Firebird también va perfecto para entornos pequeños de red, e incluso tiene una versión "embebida" para sistemas locales.

Aparte de eso, elevateDB también está muy bien, es muy completo.

[elguille]

Otra opción es MYSQL o MariaDB (gratuitos) con MYDAC https://www.devart.com/mydac/ de pago, que trae todos los componentes equivalentes de la paleta BDE, yo lo he hecho y funciona perfectamente, naturalmente hay que retocar el codigo pero sin demasiadas complicaciones. Eso si, si abres una tabla de un millon de registros los lleva todos a memoria, pero creo que es asi con cualquier componente que funcione como el TTable.
Devart tambien ha desarrollado https://www.devart.com/dac.html para multiples BD, pero estos no lo he probado.

[manelb]

Saludos a todos…

En nuestro caso, una de las aplicaciones todavía la tenemos en paradox + BDE y desarrollo en Delphi 2006.

Hemos hecho pruebas instalando el BDE en Delphi 10.2CE para valorar una posible migración en dos fases: primero Delphi i luego BD.

En principio no hemos tenido ningún problema, sólo un comportamiento extraño con el uso de los “Alias” creados en el BDE.

-El caso es que en algunos ordenadores, al ejecutar el programa nuevo creado en D10 no reconoce los alias que están creados de forma persistente con el BDEAdministrator, pero en cambio funciona perfectamente si hay una instancia abierta del programa antiguo creado en D2006 en el mismo ordenador.
-En otros casos, si hay una instancia abierta en el mismo ordenador del programa antiguo D2006 no se ejecuta el nuevo D10, y se debe cerrar el programa D2006 para ejecutar el D10.
-Y en otros ordenadores pueden funcionar los dos programas D2006 y D2010 sin ninguna restricción.

No hemos podido detectar relación casusa efecto entre los ordenadores afectados para sacar conclusiones.

La solución que parece funcionar es crear el Alias al entrar en el programa si no se reconoce.

Alguien más ha tenido este comportamiento extraño??


Saludos

[Javierus]

En principio no hemos tenido ningún problema, sólo un comportamiento extraño con el uso de los “Alias” creados en el BDE.


Estoy exactamente en la misma situación que tú: preparando la migración de 2007 a D10, sobre una CE con BDE, para migrar primero el entorno y luego la BD, aunque quizás lo haga al revés, dependiendo de la BD y componentes que elija. Me estoy planteando ElevateDB, porque me la han recomendado por el rendimiento del componente tipo TTable que tiene

En cuanto al BDE, yo en ejecución no utilizo alias persistentes, así que no te puedo decir. ¿Podría tener que ver con la VirtualDataStore de Windows?

[manelb]

Saludos Javierus...


En cuanto al BDE, yo en ejecución no utilizo alias persistentes, así que no te puedo decir. ¿Podría tener que ver con la VirtualDataStore de Windows?

La verdad es que nunca había oído este concepto : VirtualDataStore de Windows.

Voy a investigar a ver que encuentro...

Gracias por el comentario.

[Javierus]

nunca había oído este concepto : VirtualDataStore de Windows..

My fault... Es VirtualStore
https://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/please-explain-virtualstore-for-non-experts/d8912f80-b275-48d7-9ff3-9e9878954227
Esto puede hacer que en el BDEadmin haya unos Alias distintos de los que ve un programa

[manelb]

... Es VirtualStore


Hola Javierus.
No encontraba nada por VirtualDataStore referente a esto, solo referencias a máquinas virtuales :confused:

Ahora sí sé de que estás hablando, voy a investigarlo...

Gracias de nuevo