porque es tan complidado importar datos de excel a delphi

[Rofocale]

Hola a todos estuve leyendo casi todos los hilos sobre el tema de excel en delphi he probado casi todos, funcionan pero no al 100% a veces falla.. queria importa datos a un dbgrid desde un boton y tambien si es que solo seleciono y copio los datos de la hoja de excel con un control + v pegarlos en dicho dbgrid
en visual studio claro que se hace de una manera super sencilla.. pero no encuentro nada en delphi que sea sencillo.. alguien por ahi que lo aia hecho ?

gracias

[Casimiro Notevi]

No sé hasta qué punto es difícil o sencillo, pero debes tener en cuento un "detalle": excel usa un formato privativo y cerrado, cuyo dueño es microsoft. Visual studio es de microsoft. Ahí tienes la solución al enigma.
Cualquier programa, utilidad, función, etc. que quiera leer datos de excel (o de cualquier formato cerrado y privativo) tiene que recurrir a la "ingeniería inversa", y por lo tanto, nunca podrá ser tan efectiva como conocer perfectamente la estructura del archivo que se trata de leer, ya que al ser secreto, sólo se puede usar el "prueba y error" hasta dar con una solución aceptable.

[mamcx]

El que el formato sea privativo no es para nada el verdadero problema - es un problema tangencial?, si -. Oracle y Sql Server tienen formatos privados y eso para nada impide que sea de facil y dificil lectura.

Mi trabajo en http://www.elmalabarista.com ha sido en parte el de interfazar sistemas. De todo tipo (sql, textos, apis, diferentes motores sql, diferentes lenguajes y plataformas) y el que el formato interno del programa sea o no propietario no es el factor determinante en que sea facil o dificil de leerlo por medios externos.

La razon ppal es esta:

Excel es un programa de usuario/GUI

La funcionalidad de ser de facil "exportacion" es un añadido posterior. Un hack. Como todo programa que se le hackea esta funcionalidad aposteriori la cosa queda floja (empezando porque el codigo original de la mayoria de las GUI esta mezclado y requiere esfuerzo aislar la funcionalidad de parseo de datos de todo lo demas).

Una parte que no se puede obviar es que es un program de GUI:

Es por eso que MS advierte:

http://support.microsoft.com/kb/257757

Actualmente Microsoft no recomienda ni proporciona soporte técnico para la automatización de las aplicaciones de Microsoft Office desde una aplicación o componente cliente desatendido no interactivo (como ASP, DCOM y servicios de NT), ya que Office puede mostrar un comportamiento inestable y quedar interrumpido al ejecutarse en este entorno.

Al correr como un proceso de usuario y no ser un programa cliente/servidor, el cargar excel es cargar todo excel. Y solo excel entiende a la perfección el formato de excel. Y cualquier otro programa que trate de reversar ese formato va a tener líos. Ademas, ese formato es un formato de *cliente*, no esta hecho para ser accesado de forma simultánea.

El que sea cerrado es, en mi opinión, una afirmación que no se debería de intentar hacer que Excel funcione como una BD. NO LO ES.

Aquí es donde la diatriba de lo privativo sale a relucir. Que es cerrado. Eso es tangencial al problema -porque igual el hecho ineludible es que excel es un programa de usuario, monolítico-. Quien haya hecho un programa monousuario sabra que aun dando la especificacion perfecta de ese formato de archivo a otro programador *sabe* que ese otro programador no podra alcanzar 100% de compatibilidad con ese formato, porque ese formato esta diseñado para andar al ritmo de la app - por ejemplo, de un momento a otro, ese formato debe permitir embeder una imagen y como se *ve* la imagen esta amarrado a la implementación de el GUI-.

Esto es el problema #1. Excel es un programa para ser usado, y entendido, por personas aleatorias. No por maquinas aleatoria. Todo programa que tenga el estilo http://es.wikipedia.org/wiki/WYSIWYG es inherentemente complicadisimo de parsear.

Y eso, que el hecho de que Excel pueda ser usado como formato de intercambio es algo que a MS le conviene. Y es por eso que el nuevo formato, es un intento de hacerlo mas facil:

http://en.wikipedia.org/wiki/Microso...ML_Spreadsheet

Y aun asi, anque el formato es texto, sigue siendo un lio, porque?:

----
Un ejemplo notable, y eso que es un formato estandar, abierto, de texto y todo eso, es HTML. Pasear HTML es de lo mas jodido del mundo. Porque? Porque el HTML lo escriben personas. Eso hace que sea posible tener una gigantesca cantidad de HTML dificil de parsear:

http://stackoverflow.com/questions/7...tml-with-a-reg
http://www.codinghorror.com/blog/200...-shopping.html

Es posible que alguien conteste que es mentira: Parsear html es facil!. Eso es porque a)No sabe de lo que habla b) Realmente no esta en el negocio de parsear CUALQUIER html, como ocurre con un webcrawler c) Quizas ha olvidado que los navegadores NO ESTAN DE ACUERDO EN COMO LEER HTML! y por eso tiene diversos incompatibilidades, a pesar de que el html esta estandarizado.

Si se sigue creyendo que el problema es tan simple como lo de abierto, cerrado, libre, open source, muy facil de demostralo. Ir a

http://www.whatwg.org/specs/web-apps...ork/multipage/

Y crearle un cliente (navegador) que lo lea.

A ver que tan facil le parece.

Un razon secundaria y derivada de lo anterior:

Excel no tiene una estructura de datos de facil lectura.

Osea, no tiene un esquema. Es de libre creacion. Y de libre deformacion!

Por ejemplo, en los motores SQL es muy facil hacer introspeccion de datos (se puede usar un SQL para traer la estructura y definicion de las tablas) y los tipos de datos estan marcados y definidos.

Excel, por el contrario, no tiene nada de eso -osea a un nivel de "facil"-. Es como cojer un archivo de texto que alguien escribio de cualquier manera sin pensar en declararle una estructura.

Es posible que ingenuamente se piense que es culpa de MS (por lo malvado que es y todo eso), pero piensen un poco en lo que implicaria *hacer* un formato de hoja de calculo que sea facil de parsear por maquina - o similarmente, como le puede hacer un programador de MS en hacer lo mismo para Excel, aun teniendo código fuente de excel y todo eso-.

Realmente, pienselo un poco:

Un usuario le puede meter una imagen en medio de los datos de una tabla, la cual puede tener datos de forma arbitraria, copy-pasteada de otros sistemas, incompleta y para nada estructurada.

Ahora digamos que quiero extraer esos datos. Como le hago?

Es una tarea BIEN difícil. El que solo Excel sea el programa 100% capaz de leerse a si mismo no solo es una cuestion de lo maldadoso que es MS, es un asunto de limitaciones reales y practicas del problema en cuestion.

Para los programadores que solo saben de hablar con bonitas BD relacionales y que solo hacen interfaces CRUD quizas no le vean el lio que es hacer un programa de estas características.

----

Un maxima sobre este problema se deriva del principio de la robustez:

http://en.wikipedia.org/wiki/Robustness_principle

Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, liberal in what you accept").

Formatos como excel, word, html son MUY liberales en cuanto a lo que aceptan. Aceptan basura y hacen esfuerzo absurdos en interpretar lo que esa basura significa.

Eso los convierte en inherentemente liosos de entender.

---------
Otro ejemplo del mismo tema (con formato texto, libre y open source):

http://search.cpan.org/~adamk/PPI-1.215/lib/PPI.pm

The ability to read, and manipulate Perl (the language) programmatically other than with perl (the application) was one that caused difficulty for a long time.

The cause of this problem was Perl's complex and dynamic grammar. Although there is typically not a huge diversity in the grammar of most Perl code, certain issues cause large problems when it comes to parsing.

Indeed, quite early in Perl's history Tom Christenson introduced the Perl community to the quote "Nothing but perl can parse Perl", or as it is more often stated now as a truism:

"Only perl can parse Perl"

Ven? Solo el program cliente (perl) puede interpretar correctamente su estructura (perl).

Esto es el porque convertir el codigo fuente de un lenguaje a otro es lioso.
------------

Ahora que se tiene los ejemplos y el ppio de ingeniera el cual demuestra que intentar que un cliente externo sea 100% compatible contra el cliente "nativo" es fundamentalmente imposible, es donde hay que pasar a como se arregla el problema.

Lo que sucede a menudo, es simplemente aceptar que interfazar datos e intenciones entre sistemas es una tarea liosa y destinada a fracasar si se quiere la perfección. Así que simplemente, se hace el mejor esfuerzo posible y punto - Eso es lo que hace un navegador, y 300 millones de dolares anuales-

Lo ideal, es que si hay un programa que fundamentalmente esta incapacitado para trasmitir de forma agnóstica sus datos a otros programas, es intermediar con un formato o sistema alterno que no sufra esas deficiencias.

Por eso es que si se va a pasar datos a excel, es preferible usar CSV, XML, conexión directa a una BD, etc.

Lo segundo, es dejar que sea excel quien lea excel, y hacer la exportación desde un plugin instalado dentro del mismo excel.

Osea, en general, hay un sistema que realmente esta diseñado para ser leído e interpretado por múltiples sistemas (ej: Una BD) y este, en contra del principio de la robustez, es tan estricto en lo que lee como en lo que envía, y lo menos ambiguo posible, y luego eso datos son "renderizados" en un programa cliente (como excel).

[Casimiro Notevi]

Empezado por mamcx

El que el formato sea privativo no es para nada el verdadero problema.

Por supuesto que es un problema, grave, gravísimo, principal, esencial, primordial, verdadero y gran problema.

[Combat-F2D]

el problema es que leemos cuatro revistas de PCMUNDO, etc, y cualquiera se cree que con excel se hace todo........, esto ha producido a la larga que se emplee algo que no es mas que una hoja de calculo, y por supuesto con limitaciones, se emplee por lo no entendidos como una POTENTE Base de Datos......

es por ello que esto ha conducido a que no se porque todo el mundo emplee el excel (bueno si, a MS le interesa), como archivo de importacion/exportacion para intercambio de info; lo digo porque lo estoy padeciando todos y cada uno de los dias que me pasa(me cambian formatos de Hoja$1) y me torean.

y pregunto para que existen archivos CSV, o sin ir mas lejos, esos famosos archivos DBF, que son la mar de majos para estas cosas???????

[roman]

Empezado por Rofocale

Hola a todos estuve leyendo casi todos los hilos sobre el tema de excel en delphi he probado casi todos, funcionan pero no al 100% a veces falla.. queria importa datos a un dbgrid desde un boton y tambien si es que solo seleciono y copio los datos de la hoja de excel con un control + v pegarlos en dicho dbgrid

¡Vaya regañiza que te has llevado! Pero algo es cierto: deberías especificar más qué es lo que no te funciona y quizá se pueda hacer algo.

Mario: no conozco visual studio pero voy a dar por buena la palabra del compañero:

Empezado por Rofocale

en visual studio claro que se hace de una manera super sencilla..

¿Cómo encaja VS en tu larga argumentación de que sólo Excel entiende Excel y no, como dice Casimiro, que sólo MS entiende MS?

// Saludos

[mamcx]

Empezado por roman

Mario: no conozco visual studio pero voy a dar por buena la palabra del compañero:



¿Cómo encaja VS en tu larga argumentación de que sólo Excel entiende Excel y no, como dice Casimiro, que sólo MS entiende MS?

// Saludos

Nada mal de hecho. Que al compañero le parezca o no facil X tarea entre un lenguaje u otro es en parte diseño de API y como se ataca el problema.

Es como decir que hacer un GUI es mas facil en Delphi que en C++ - y teniendo en cuenta que Delphi es una MEJOR interpretación del API nativo de windows (pre-NET) que C++ hecho por MS, sigue mostrando que el acceso al código y el estar pegado a el no significa obligatoriamente una mejor implementación. Es algo que vivo en mi trabajo, donde hago implementaciones (con www.bestsellerapp.com) mucho mas rapido y mejor que las mismas casas de ERP que intentan hacer un acceso móvil a su propio ERP.

Todo esta en el diseño y aproximación.

Ahora la realidad es que Delphi - mas bien la comunidad en general - esta muy atrasado en cuanto a integraciones con un montón de cosas que se usan ahora (ej: Motores NOSQL, cloud, apis Web, y basicamente de todo lo que sale en http://www.hackerne.ws/ y thechangelog.com), y en el caso de Office, mucho se ha avanzado tambien. Si me dieran a escoger, utilizaria mas facil el API de .NET que el delphi, porque esta mas maduro y actualizado. Que sea hecho por MS? Eso es secundario. Lo que uno escoge como herramienta es la que sea mejor para resolver la tarea, increiblemnte a veces MS la tiene. Otras veces - incluso para sus propios produtos - no la tiene.

Ahora habría que saber exactamente que es lo que quiere el compañero -podría ser que al final la tarea especifica es en realidad facil de resolver, incluso en delphi, y que en .NET este mas directo el como resolverla -

Eso me pasa por emocionarme con el tema -porque integrar es de lo que mas hago-. El orden es saber primero exactamente cual es el problema y luego como resolverlo

[roman]

Disculpa que lo diga, Mario, pero hay veces que pareces político.

El punto es que en tu primera argumentación esgrimes que la única forma de hacer un traslado de datos 100% perfecto con Excel, es con Excel mismo. Pero si en VS puede hacerse de manera sencilla, entonces algo falla en tu argumentación.

De hecho, el compañero, a mi juicio, ha recibido una larga disertación que no viene del todo al caso. Para empezar, citas una entrada del soporte de Micosoft que, claramente habla de las dificultades de automatizar Office en un servidor. Ahora bien, no creo haber leido para nada que tal fuera el caso del compañero. Así como tampoco me parece haber visto que mencionara usar Excel como una base de datos.

La conveniencia o no de usar Excel como transporte de datos podría discutirse, pero la realidad es que muchos entornos tienen que lidiar con eso: importar datos de Excel a una base de datos.

// Saludos

[[Delphius]]

No todo se puede, ni debiera, automatizar.
¿Quieren pasar las cosas desde Excel a Bases de Datos?
Hagan el sistema, y luego se pagan a 5 tipos que manden teclazos y pasen la info de un lado a otro.
Al final eso les dará menos dolores de cabeza. Que no quieran pagar a 5 tipos porque les sale caro, ya es otra cosa. Y esa es la gran verdad, no quieren poner un peso y esperan que la máquina les haga el trabajito de gratis.
Lo que se pueda hacer de forma automática, que se haga... para el resto mastercard y pagar a datas entrys. No se puede esperar magia, sea un producto privado o libre. La magia se la da a los chicos de 5 años para entretener en las fiestas de cumpleaños.

Mamx, te mandaste un discursito que poco y nada sirve, me parece. Rofocale empieza a buscarle las vueltas y ver el modo de proponer alternativas. Incluso se valen escenarios en donde se conviva, temporalmente, con ambas cosas como transición. Piensa, analiza las posibilidades y formas de sostener el proyecto... luego que el jefecito se haga cargo y sepa que por más que la informática esté para hacer más fácil la vida, no todo se puede.

Saludos,

[Casimiro Notevi]

Empezado por roman

Disculpa que lo diga, Mario, pero hay veces que pareces político.

+1

[mamcx]

Empezado por roman

El punto es que en tu primera argumentación esgrimes que la única forma de hacer un traslado de datos 100% perfecto con Excel, es con Excel mismo. Pero si en VS puede hacerse de manera sencilla, entonces algo falla en tu argumentación.

Entonces es falso que el traslado de datos desde Excel no es la forma mas facil? Acaso mencione que es imposible que un client externo logre esta tarea? Lo que argumente es que es fundamentalmente imposible que uno externo, contra un sistema que no esta diseñado para tal proposito, no podra lograr la funcionalidad y compatibilidad a un nivel perfecto, y di las razones por las cueles es asi.

Empezado por roman

De hecho, el compañero, a mi juicio, ha recibido una larga disertación que no viene del todo al caso.

Lo cual tienes 100% la razon. El problema es que respondi mas a lo que menciono casimiro, que el problema en cuanto a su lectura era porque excel es propietario, aunque igualmente carecemos ambos de razones para respuesta alguna, igual, no sabemos cual realmente es el problema.

Nos debieron haber sacado por desvirtuar el hilo, mas sobre todo yo....

[Rofocale]

Bueno el problema no era pagar a data entrys lo que pasa es que ya se tiene un excel en donde se trabaja y se ha trabajado siempre y cada dia o semana se modifica y el programa que estaba haciendo era para generar unos txt que debo importar en la pagina de un banco, por ello pensaba el porque es tan dificil, no existen muchos componentes en delphi para temas de excel verdad ? bueno en el trabajo hay una aplicacion que la hicieron con visual studio y que si selecionabas los campos de la hoja de excel y lo copiabas al portapapeles y pegabas en el datagrid del programita con control + v este pasaba de inmediato los datos.. pues queria hacer algo asi con delphi.. pero hasta ahora no he encontrado la forma..
por eso les escribia para ver si por ahi alguien si tenia mas o menos alguna solucion o algo que le haya funcionado perfecto

muchas gracias compañeros

[Casimiro Notevi]

Empezado por Rofocale

bueno en el trabajo hay una aplicacion que la hicieron con visual studio y que si selecionabas los campos de la hoja de excel y lo copiabas al portapapeles y pegabas en el datagrid del programita con control + v este pasaba de inmediato los datos..

Habría que saber qué es exactamente.

[mamcx]

Pues asi como lo describes es algo relativamente facil.

Lo que pasa es que comparas un programa ya hecho contra la perspectiva de uno por hacer. Obviamente el ya hecho parecera mas facil

Ademas, en mi experiencia he visto que no a muchos programadores les sale facil el proceso de integrar sistemas diferentes, y algunos terminan haciendo un montón de vueltas innecesarias.

El truco de todo esto es conocer muy bien como funciona el programa del cual se va a leer, osea, excel. Tambien conocer las diversas formas de acceder a este.

Hay por lo menos 4.

1) Usa automatizacion OLE
2) Usando conexion ADO
3) Leyendo directamente el archivo sin tener excel para nada
4) Cargando el programa dentro de excel, como un add-in

Aqui te exponen las 2 primeras, que son las mas comunes

http://delphi.about.com/od/database/l/aa090903a.htm

La tercera forma

http://www.scalabium.com/xls/xlslib.htm
http://www.vclcomponents.com/s/0__/delphi_excel_reader/

y la cuarta:

http://www.add-in-express.com/docs/v...ion-addins.php

----

Sin embargo, la forma que describes explota una funcionalidad elemental del sistema operativo y NO TIENE NADA QUE VER CON EXCEL.

De hecho, que truco tan bueno!

Estas describiendo que usan el portapapeles para pasar los datos.

Es asi:

Abre un editor de texto. Copia una seleccion de celdas desde excel. Te queda algo asi:

tiempo size tipo
zip 2:10 251.773 normal
zip 1:36 283.268 rapida
rar 2:28 171.434 normal
rar 1:53 187.197 rapida
qpress 1:00 402.056 1
qpress 0:46 345.340 3
lzo 0:57 411.986 3
7zip 1:32 173.304 fast

Ves? Eso es supersimple de interpretar. Lo cargas en un TSTringlist y partes por TAB/espacios y listo.