Estimados Colegas,

Se me ocurri que uno de los mayores obstculos a la hora de migrar hacia 
una arquitectura Cliente-Servidor pasa por la forma de expresar en SQL las 
operaciones a las que acostumbramos realizar con DBF.

Para ser ms claros:
Cmo expresaramos las siguientes propuestas?

Sea la tabla "TABLA.DBF" con la siguiente estructura:
CODCLI, C, 10, 0   CODigo de CLIente (en otra cultura: ID del Cliente).
NOMCLI, C, 40, 0   NOMbre del CLIente
DOMCLI, C, 40, 0   DOMicilio del CLIente: Calle, nmero, etc.
CFISCAL, C, 15,0   Clave Fiscal (ID Fiscal segn el Pas).
FSALDO,  D,  8, 0   Fecha del Ultimo Movimiento
SALDO   , N, 10, 2  Estado de la Cuenta Corriente del Cliente. (SALDO > 0, 
Nos debe).

Indices:
TABLA1.NTX:   Clientes ordenados ascendentemente por Fecha de Movimiento.
CODCLI+DTOS(FSALDO)

TABLA2.NTX:  Clientes ordenados ascendentemente por Saldo y Fecha de 
Saldo.
STR(SALDO,10,2)+DTOS(FSALDO)

a) USE Tabla.dbf:
SELECT * FROM Tabla

b) USE TABLA INDEX TABLA1:
SELECT * FROM Tabla ORDER BY CODCLI, FSALDO ASC

c) USE TABLA INDEX TABLA2:
SELECT * FROM Tabla ORDER BY SALDO ASC, FSALDO ASC

Por ahora, usando ODBCDBE se puede usar SQL de la siguiente forma:

cSQL := "SELECT..."
USE &(cSQL) ALIAS ULTMOV
BROWSE()

Saludos

Jos Luis Otermin
Alaska Software

On Wed, 12 Jan 2011 22:42:42 -0300, Jose Luis Otermin wrote:

> Estimados Colegas,
> 
> Se me ocurrió que uno de los mayores obstáculos a la hora de migrar hacia 
> una arquitectura Cliente-Servidor pasa por la forma de expresar en SQL las 
> operaciones a las que acostumbramos realizar con DBF.
> 
> Para ser más claros:
> ¿Cómo expresaríamos las siguientes propuestas?
> 
> Sea la tabla "TABLA.DBF" con la siguiente estructura:
> CODCLI, C, 10, 0   CODigo de CLIente (en otra cultura: ID del Cliente).
> NOMCLI, C, 40, 0   NOMbre del CLIente
> DOMCLI, C, 40, 0   DOMicilio del CLIente: Calle, número, etc.
> CFISCAL, C, 15,0   Clave Fiscal (ID Fiscal según el País).
> FSALDO,  D,  8, 0   Fecha del Ultimo Movimiento
> SALDO   , N, 10, 2  Estado de la Cuenta Corriente del Cliente. (SALDO > 0, 
> Nos debe).
> 
> Indices:
> TABLA1.NTX:   Clientes ordenados ascendentemente por Fecha de Movimiento.
> CODCLI+DTOS(FSALDO)
> 
> TABLA2.NTX:  Clientes ordenados ascendentemente por Saldo y Fecha de 
> Saldo.
> STR(SALDO,10,2)+DTOS(FSALDO)
> 
> a) USE Tabla.dbf:
> SELECT * FROM Tabla
> 
> b) USE TABLA INDEX TABLA1:
> SELECT * FROM Tabla ORDER BY CODCLI, FSALDO ASC
> 
> c) USE TABLA INDEX TABLA2:
> SELECT * FROM Tabla ORDER BY SALDO ASC, FSALDO ASC
> 
> Por ahora, usando ODBCDBE se puede usar SQL de la siguiente forma:
> 
> cSQL := "SELECT..."
> USE &(cSQL) ALIAS ULTMOV
> BROWSE()
> 
> Saludos
> 
> José Luis Otermin
> Alaska Software

El manejo de datos exclusivamente con herramientas de Alaska es muy
limitado y excesivamente caro.
No vale la pena transitar ese camino.

Saludos
Angel

Angel,

> El manejo de datos exclusivamente con herramientas de Alaska es muy
> limitado y excesivamente caro.
> No vale la pena transitar ese camino.

Podras demostrar lo que nos informas ms arriba?

Omnia probate.

Gracias

Jos Luis Otermin
Alaska Software

Angel,

A ver, tampoco hay que ser tan radical, para eso ya tenemos a los políticos 

ODBCDBE funciona, no tienes la misma flexibilidad que con la librería de Boris, ni la potencia de usar los APIs nativos de algunas bases de datos, pero el caso es que funciona.

Caro si que es, o al menos para mi bolsillo pero bueno eso es otro tema.

A mi me gustaría que más que cerrar puertas abrieras otra alternativa hablando un poco de tu experiencia con los APIs nativos de sqlite y postgres, bueno si tienes tiempo de sobra y te apetece, claro 

Como me dijo un cliente un día, a veces la solución más conveniente, no tiene por que se precisamente la mejor ni la más eficiente, sino que muchas veces intervienen una serie de factores como la disponibilidad, la manera en que tengamos estruturado el codigo que ya existe, o el conocimiento que tengamos sobre una herramienta en concreto. 

El caso con ODBCDBE es que hay gente aqui que ya tiene una subcripción profesional porque ha necesitado alguno de los productos que se incluyen en el paquete, a veces hay necesidad de acceder a una base de datos via ODBC, bueno pues si tienes la herramienta a mano y si con las carácterísticas que tiene te puedes apañar pues podría merecer la pena hacer el intento.

Los tips de Jose Luis pues siempre son utiles y no quita que no podamos probar otros caminos si vemos la necesidad o la conveniencia.

Un abrazote,

Pablo

On Thu, 13 Jan 2011 17:05:07 +0100, Pablo Botella wrote:

> Angel,
> 
> A ver, tampoco hay que ser tan radical, para eso ya tenemos a los políticos 
> 
> ODBCDBE funciona, no tienes la misma flexibilidad que con la librería de Boris, ni la potencia de usar los APIs nativos de algunas bases de datos, pero el caso es que funciona.
> 
> Caro si que es, o al menos para mi bolsillo pero bueno eso es otro tema.
> 
> A mi me gustaría que más que cerrar puertas abrieras otra alternativa hablando un poco de tu experiencia con los APIs nativos de sqlite y postgres, bueno si tienes tiempo de sobra y te apetece, claro 
> 
> Como me dijo un cliente un día, a veces la solución más conveniente, no tiene por que se precisamente la mejor ni la más eficiente, sino que muchas veces intervienen una serie de factores como la disponibilidad, la manera en que tengamos estruturado el codigo que ya existe, o el conocimiento que tengamos sobre una herramienta en concreto. 
> 
> El caso con ODBCDBE es que hay gente aqui que ya tiene una subcripción profesional porque ha necesitado alguno de los productos que se incluyen en el paquete, a veces hay necesidad de acceder a una base de datos via ODBC, bueno pues si tienes la herramienta a mano y si con las carácterísticas que tiene te puedes apañar pues podría merecer la pena hacer el intento.
> 
> Los tips de Jose Luis pues siempre son utiles y no quita que no podamos probar otros caminos si vemos la necesidad o la conveniencia.
> 
> Un abrazote,
> 
> Pablo
> 
> 
> 
> 
> 
> 
> 
>

La respuesta va para ambos.
Como bien tu sabes pablo yo uso sqlite y postgresql con Alaska pero con el
aditamento de ot4xb.
Obviamente Alaska nunca va a refrendar ese camino porque ellos en vez de
hacer lo que la gente necesita siempre se empeñan en hacer los que sus 3rd
party providers ya han hecho ( y mal ). Valga como ejemplo el caso
sqlexpress vs odbcdbe. Del cual el segundo es varias veces mas caro y esta
lleno de bugs.
En cambio nunca temrinaron de pulir la tecnologia rushmore que haria que
los filtros se pudieran usar casi con la eficiencia de sql ni tampoco han
suplido herramientas que fueron solicitadas hace de mas de 10 años.
Un DBE que trabaje en memoria y un DBE cliente servidor como el de ADS.
Es evidente que se sienten seguros para conpetir contra sus cientes pero no
contra sus colegas.
La libreria de acceso a sqlite la publique hace varis años pero nadie la
entendio o nadie quiso arriesgar usar una libreria de "un desconocido".
Asi que volvemos a estar en las manos del criterio unilateral de San Oso.
Yo sinceramente no le veo una salida facil al tema.
El que quiera usar SQL puede usar los wrappers para sqlite mios, el de
Pablo para PG y el de Hector para Mysql. todos ya han sido publicados en
xfree pero su uso ha sido congelado por la falsa promesa de arctica lanzada
hace 4 años que impide que las herramientas de terceros (aun las gratuitas)
se impongan como de uso comun entre la comunidad xbase.
Que podemos esperar de ua empresa que obra en contra de su propia comunidad
de clientes ?

Mi humilde opinion
Angel

PD: No pienso seguir argumetnando sobre este tema, creo que mi pensamiento
ya ya sido bien explicitado. Usará alaska mientras me aporte algo y par
mantener sistemas en produccion. Pero para las cosas nuevas mis pasos ya se
han encaminado a otros rumbos multiplataforma multi GUI y con gente entre
la cual mi opinion vale algo ( aunque sea un poquito ). Inisto, aqui no hay
animosidades, solo un poco de desilucion pero bueno la tecnologia tiene sus
caminos sinuosos y lo que hoy es una verdad aparente mañana tal vez sea un
error. El tiempo dira .

Angel,

> La respuesta va para ambos.
> Como bien tu sabes pablo yo uso sqlite y postgresql con Alaska pero con el
> aditamento de ot4xb.

Como podrs comprobar, la interfaz de Xbase++ y C++ funciona ptimo.
Pablo ha basado OT4XB en ella y todos la alaban.
No slo la entrega sin cargo sino que la ha documentado de maravillas.

> Obviamente Alaska nunca va a refrendar ese camino porque ellos en vez de
> hacer lo que la gente necesita siempre se empean en hacer los que sus 3rd
> party providers ya han hecho ( y mal ).

Si fabricaras tecnologa, cmo protegeras las inversiones hechas por tus 
asociados tecnolgicos? (Hablamos de ADS, SQLExpress, eXpress++, TopDown, 
etc).
Estando en este gremio supongo que no te es desconocido el trmino 
"contrato", el cual se firma entre dos empresas que colaboran 
sinrgicamente. Por se y otros motivos (que no puedo discutir aqu), se 
protege a quienes desarrollan tecnologa basada en Xbase++.

>Valga como ejemplo el caso
> sqlexpress vs odbcdbe. Del cual el segundo es varias veces mas caro y esta
> lleno de bugs.

ODBCDBE ilimitado est includo en la susbscripcin profesional la cual trae 
una docena de paquetes (ver 
http://www.alaska-software.com/products/subscription.shtm)
y SQLExpress cuesta aproximadamente lo mismo en su tambin versin 
ilimitada.
Asumo que la afirmacin "es varias veces ms caro" debe referirse a algun 
escenario metafrico.

> En cambio nunca temrinaron de pulir la tecnologia rushmore que haria que
> los filtros se pudieran usar casi con la eficiencia de sql ni tampoco han
> suplido herramientas que fueron solicitadas hace de mas de 10 aos.

Lo de las herramientas habra que puntualizar un poco. Alaska Software 
provey WIS pero la comunidad decidi no utilizar esa tecnologa y se 
discontinu.

Sin embargo, el diseador de formularios se ampli, se agreg interfaces con 
tecnologas recientes (.NET, ActiveX, etc), se adapt a nuevos S.O. (Win95 
fue la interfaz original),  se agregaron componentes, se liberaron las 
interfaces para poder disear con mayor libertad y varias cosas ms que 
escapan a mi memoria.

> Un DBE que trabaje en memoria y un DBE cliente servidor como el de ADS.

La comunidad que quiere usar ADS y no quiere pagar su precio quedara muy 
contenta con tal DBE, pero en lo personal yo desaconsejara a Alaska de 
agredir a los fabricantes de ADS con semejante maniobra.

> Es evidente que se sienten seguros para conpetir contra sus cientes pero 
> no
> contra sus colegas.

Xbase++ no compite contra los clientes. Quiz quisiste decir otra cosa.

> La libreria de acceso a sqlite la publique hace varis aos pero nadie la
> entendio o nadie quiso arriesgar usar una libreria de "un desconocido".

Quiza desde la experiencia personal puedas comprender el xito de Xbase++ 
entre sus usuarios ya que confan en l.
Te parece que nadie quiso arriesgarse o quiz la documentacin pudiera no 
ser muy clara? No us SQLite pero tampoco me enter que la habas publicado.
Quiz la baja tasa de uso se debiera al poco estado pblico que tom su 
liberacin.
Es muy difcil instalar un producto nuevo en un mercado conservador.
No te desanimes, si publicas la direccin de descarga en este foro es 
probable que los colegas le den una oportunidad.

> Asi que volvemos a estar en las manos del criterio unilateral de San Oso.

Bueno, gracias por el elogio, pero no creo que San Oso pueda dirigir al 
mercado indicndole lo que debe y no debe hacer.

> El que quiera usar SQL puede usar los wrappers para sqlite mios, el de
> Pablo para PG y el de Hector para Mysql. todos ya han sido publicados en
> xfree.

Bueno, quiza se te haya olvidado que la iniciativa XFree se debi a una idea 
de quien escribe. As que comparto tu deseo de ayudar a la comunidad pues es 
se el espritu del grupo.

> pero su uso ha sido congelado por la falsa promesa de arctica lanzada
> hace 4 aos que impide que las herramientas de terceros (aun las 
> gratuitas)
> se impongan como de uso comun entre la comunidad xbase.

Por favor, no pienses que aquellas acciones que no coinciden con tus deseos 
se tratan de iniciativas maliciosas.
La Teora de las Expectativas Racionales 
(http://es.wikipedia.org/wiki/Teora_de_las_expectativas_racionales) explica 
con claridad cmo dos agentes econmicos (nosotros lo somos) concurren al 
mercado y realizan operaciones contrarias (uno compra lo que el otro vende) 
y sin embargo ambos consideran que han salido ganando. Siempre existe una 
lgica detrs de toda decisin empresaria aunque nuestra limitada 
informacin no nos permita comprenderla.

> Que podemos esperar de ua empresa que obra en contra de su propia 
> comunidad
> de clientes ?

Si Xbase++ fuera en contra de sus propios usuarios ya habra dejado de 
existir.

Comprendo que tuvieras expectativas y stas pudieran no haber sido colmadas 
en cantidad, calidad o momento deseados y por eso asumo que no existe 
animosidad sino una queja por las esperas.

Sin embargo, he visto funcionando la tecnologa anunciada y otras que ni 
siquiera han sido consideradas por la comunidad. Las expectativas son una 
buena seal porque demuestran que existe fe en Xbase++ y su capacidad 
evolutiva.

No puedo facilitar informacin privilegiada a la cual tengo acceso, pero 
puedo decirte que tu fe no se ver defraudada. Es difcil sostener la fe 
cuando se ha visto retrasado el lanzamiento de Arctica, pero creme que 
valdr la pena.

Gracias por tu transparencia y compartir tus pensamientos con todos.
Un abrazo

Jos Luis Otermin
Alaska Software

Jelou Pablo!

> Los tips de Jose Luis pues siempre son utiles y no quita que no podamos 
> probar otros caminos si vemos la necesidad o la conveniencia.

Muchas gracias por la chanza 
Trato de ayudar a quienes por timidez no se animan a preguntar cosas que 
podran ser elementalmente bsicas para un experto pero que son el primer 
obstculo que un programador se encuentra (mi caso) cuando decide 
evolucionar.

No soy ningn genio y de hecho las preguntas que hago son con toda franqueza 
las mismas que me hice en su momento.

Si los colegas se animaran a preguntar en este espacio, tendramos una 
fuente de excelentes soluciones probadas por cientos de personas pues los 
usuarios de Xbase++ tienen ideas muy ingeniosas, por cierto.

Un abrazo grande

Jos Luis Otermin
Alaska Software

Angel Pais avait soumis l'idée :
> On Wed, 12 Jan 2011 22:42:42 -0300, Jose Luis Otermin wrote:
>
>> Estimados Colegas,
>> 
>> Se me ocurrió que uno de los mayores obstáculos a la hora de migrar hacia 
>> una arquitectura Cliente-Servidor pasa por la forma de expresar en SQL las 
>> operaciones a las que acostumbramos realizar con DBF.
>> 
>> Para ser más claros:
>> ¿Cómo expresaríamos las siguientes propuestas?
>> 
>> Sea la tabla "TABLA.DBF" con la siguiente estructura:
>> CODCLI, C, 10, 0   CODigo de CLIente (en otra cultura: ID del Cliente).
>> NOMCLI, C, 40, 0   NOMbre del CLIente
>> DOMCLI, C, 40, 0   DOMicilio del CLIente: Calle, número, etc.
>> CFISCAL, C, 15,0   Clave Fiscal (ID Fiscal según el País).
>> FSALDO,  D,  8, 0   Fecha del Ultimo Movimiento
>> SALDO   , N, 10, 2  Estado de la Cuenta Corriente del Cliente. (SALDO > 0, 
>> Nos debe).
>> 
>> Indices:
>> TABLA1.NTX:   Clientes ordenados ascendentemente por Fecha de Movimiento.
>> CODCLI+DTOS(FSALDO)
>> 
>> TABLA2.NTX:  Clientes ordenados ascendentemente por Saldo y Fecha de 
>> Saldo.
>> STR(SALDO,10,2)+DTOS(FSALDO)
>> 
>> a) USE Tabla.dbf:
>> SELECT * FROM Tabla
>> 
>> b) USE TABLA INDEX TABLA1:
>> SELECT * FROM Tabla ORDER BY CODCLI, FSALDO ASC
>> 
>> c) USE TABLA INDEX TABLA2:
>> SELECT * FROM Tabla ORDER BY SALDO ASC, FSALDO ASC
>> 
>> Por ahora, usando ODBCDBE se puede usar SQL de la siguiente forma:
>> 
>> cSQL := "SELECT..."
>> USE &(cSQL) ALIAS ULTMOV
>> BROWSE()
>> 
>> Saludos
>> 
>> José Luis Oterminn 
>> Alaska Software
>
> El manejo de datos exclusivamente con herramientas de Alaska es muy
> limitado y excesivamente caro.
> No vale la pena transitar ese camino.
>
> Saludos
> Angel

va con onda, sin animo de ofender a nadie
yo soy un usuario que tiene sistemas que trabaja con motor de base de 
datos sql server 2005 y 2008 standard, con ODBCDBE y a mi me funciona 
de maravillas, para mi ha sido lo mejor para migrar de clipper5, ahora 
es indudable que existen otros lenguajes que manejan mejor los datos 
que alaska.-
Que tambien tengo licencias de otro lenguaje, por la necesidad de 
contar con herramientas mejores de acuerdo con los tiempos actuales.-

Hola,

A mi mujer le gusta la tortilla de patatas con cebolla, a mis hijas sin cebolla y a mi me da igual, me la como de cualquier manera. Solucion: frio todas las patatas juntas, frio la cebolla aparte, bato los huevos y en una sartén más pequeña hago 2 tortillas una con cebolla para mi mujer y para mi y otra sin cebolla para mis hijas. 

A día de hoy tenemos varias soluciones para usar SQL , ODBC con ODBCDBE (Alaska) y con SQLExpress (Boris) , wrappers nativos para sqlite ( uno de Angel y otro mio ), postgress ( Hay uno que hizo Phil  Ide y otro mio) , mysql ( de Hector) y firebird ( de Maurizio). Además hay gente que usa ADO unos con el ActiveX de Alaska y otros con el de Michael Hoffman.

Así  que tenemos un buffet de tortillas variadas listas para comer, y ademas hay algunas más que todavia no salieron de la cocina.

Pues eso, resumiendo, que me ha entrado hambre y me bajo a la cocina a tomar un vaso de leche con galletas antes de irme a dormir.

Saludos,
Pablo

Hola a todos

Entiendo a Ángel de que use este medio para trasmitir su desconformidad y 
desilusión que lo ha obligado a tomar otros rumbos

pero que no sería justo que un intercambio de opiniones se mal entienda y se 
transforme en algo personal








"Angel Pais"  escribió en el mensaje de 
noticias:1qi68spwf94cx$.1hp4hr1q7892y.dlg@40tude.net...

On Wed, 12 Jan 2011 22:42:42 -0300, Jose Luis Otermin wrote:

> Estimados Colegas,
>
> Se me ocurrió que uno de los mayores obstáculos a la hora de migrar hacia
> una arquitectura Cliente-Servidor pasa por la forma de expresar en SQL las
> operaciones a las que acostumbramos realizar con DBF.
>
> Para ser más claros:
> ¿Cómo expresaríamos las siguientes propuestas?
>
> Sea la tabla "TABLA.DBF" con la siguiente estructura:
> CODCLI, C, 10, 0   CODigo de CLIente (en otra cultura: ID del Cliente).
> NOMCLI, C, 40, 0   NOMbre del CLIente
> DOMCLI, C, 40, 0   DOMicilio del CLIente: Calle, número, etc.
> CFISCAL, C, 15,0   Clave Fiscal (ID Fiscal según el País).
> FSALDO,  D,  8, 0   Fecha del Ultimo Movimiento
> SALDO   , N, 10, 2  Estado de la Cuenta Corriente del Cliente. (SALDO > 
> 0,
> Nos debe).
>
> Indices:
> TABLA1.NTX:   Clientes ordenados ascendentemente por Fecha de 
> Movimiento.
> CODCLI+DTOS(FSALDO)
>
> TABLA2.NTX:  Clientes ordenados ascendentemente por Saldo y Fecha de
> Saldo.
> STR(SALDO,10,2)+DTOS(FSALDO)
>
> a) USE Tabla.dbf:
> SELECT * FROM Tabla
>
> b) USE TABLA INDEX TABLA1:
> SELECT * FROM Tabla ORDER BY CODCLI, FSALDO ASC
>
> c) USE TABLA INDEX TABLA2:
> SELECT * FROM Tabla ORDER BY SALDO ASC, FSALDO ASC
>
> Por ahora, usando ODBCDBE se puede usar SQL de la siguiente forma:
>
> cSQL := "SELECT..."
> USE &(cSQL) ALIAS ULTMOV
> BROWSE()
>
> Saludos
>
> José Luis Otermin
> Alaska Software

El manejo de datos exclusivamente con herramientas de Alaska es muy
limitado y excesivamente caro.
No vale la pena transitar ese camino.

Saludos
Angel