Que plataforma uso para programar?

Hola a todos

En mi trabajo estoy haciendo pequeñas aplicaciones para Excel en VBA, que con el paso del tiempo han dejado de ser tan "pequeñas" y ya estamos utilizando menus, y aplicaciones para cada caso en concreto.

En general se trata de manipular ficheros Excel, generar historicos, llevar el control de Stock a partir del fichero enviado por el cliente, control de Stocks, etc...

Pero con todo, los usuarios siguen teniendo acceso a las hojas de Excel, que puedo proteger en cada caso, pero he pensado en trasladar el VBA a otra plataforma para hacer el programa general, (que se va ampliando cada dia), a... Visual Basic?

He mirado el Visual Studio, pero ahí está el C++, El Visual Basic y otros que no conozco.

En breve me interesará poder "volcar" datos de paginas Web y basicamente tratar los datos, hacer estadisticas, etc...

Visual Basic 2010 es el que me ha parecido mas adecuado ya que tendrá que actuar en muchos PC que siguen con Windows XP y a los que les costará tiempo cambiar a 64 bits.

Que os parece si me decanto por Visual Basic 2010?

Muchas gracias.

Yo lo primero que te diría, es que si se va a hacer tan grande uses una base de datos en vez de excel. Excel no está hecho para tratar con grandes cantidades de datos, terminas con unos archivos ENORMES y lentos como trasatlánticos, cosa que no te va a pasar con una base de datos.

Si no quieres aprender c++, pues oye, el visual está bien para estas cosas, no puedo comentar nada de versiones y temas más específicos por que hace tiempo que estoy desconectado de estas cosas, pero vamos, cada dos por tres te encuentras aplicaciones de ofimática hechas con visual y van bien.

Saludos.

Nox escribió:

Yo lo primero que te diría, es que si se va a hacer tan grande uses una base de datos en vez de excel. Excel no está hecho para tratar con grandes cantidades de datos, terminas con unos archivos ENORMES y lentos como trasatlánticos, cosa que no te va a pasar con una base de datos.

+1

Una base de datos está optimizada para trabajar con tablas de datos, así que siempre será más rápida y eficiente.

japbcn escribió:

Pero con todo, los usuarios siguen teniendo acceso a las hojas de Excel, que puedo proteger en cada caso, pero he pensado en trasladar el VBA a otra plataforma para hacer el programa general, (que se va ampliando cada dia), a... Visual Basic?

Lo más directo y sencillo sería que trabajases en Access, el lenguaje es el mismo y las posibilidades para informes, validación de datos, menús, etc... mucho mayores. Con ODBC puedes trabajar con datos centralizados (ni siquiera tiene que ser Access la base de datos) y tener la interfaz en los clientes en Access.

japbcn escribió:

He mirado el Visual Studio, pero ahí está el C++, El Visual Basic y otros que no conozco.

C++ es un lenguaje de nivel más bajo que Visual Basic, para hacer lo mismo necesitas muchísimo más código. La ventaja es que permite optimizar todo mucho más... pero a menos que vayas a diseñar el programa que desbanque al Photoshop no le veo demasiado sentido.

japbcn escribió:

En breve me interesará poder "volcar" datos de paginas Web y basicamente tratar los datos, hacer estadisticas, etc...

Access tiene bastante funciones para hacer informes, te lo hará todo más fácil. No acabo de entender la idea de "volcar" datos de páginas web, ¿te refieres a importar información de Internet?, ¿o al revés, a crear una interfaz web para tu aplicación?.

Si este es el caso quizás podrías plantearte migrar progresivamente la aplicación a LAMP (Linux, Apache, MySQL y PHP) u otro servidor web. No es más complejo que trabajar en VBA, yo diría más sencillo y muchísimo más simple que el C++. Y sí mucho más flexible para crear aplicaciones accesibles por muchos usuarios desde cualquier ordenador.

Un paso intermedio sería crear tu base de datos en MySQL (o similar) y acceder a ella por ODBC desde una interfaz Access. Mientras vas refinando la base de datos y probando la interfaz web sobre la misma base de datos (o mejor una copia para pruebas ). Muchas aplicaciones corporativas, por no decir la inmensa mayoría hoy en día son aplicaciones web que se acceden en una Intranet o desde Internet.

No soy un experto programador, pero trabajo con aplicaciones web y he participado en el desarrollo de algunas. No se si conoces algo de programación web pero no es complicado, aunque pueda parecerlo al principio. Puedes bajarte un entorno de desarrollo completo y hacerlo correr en tu propio ordenador para probar antes de lanzarte a configurar un servidor dedicado.

http://www.easyphp.org

En realidad es muy simple. Yo no controlo gran cosa PHP o Phyton, aunque todo es ponerse en mis tiempos opté por una opción menos popular (porque era propietaria y no Open Source) pero muy sencilla de aprender, Coldfusion. Ahora hay una versión libre de Coldfusion que se llama Railo y es igual de simple. También tienes una instalación para Windows que trae todo lo necesario para configurar un servidor de desarrollo en tu ordenador.

http://www.getrailo.org

La ventaja (y desventaja) de Coldfusion (o CFMX que es como se llama el lenguaje) respecto a PHP o Phyton es que mezcla las funciones para acceder a la base de datos con el código HTML para diseñar la interfaz. Esto lo hace super-simple para aprender pero bastante "desordenado" para programadores avanzados.

Si tienes conocimientos previos básicos de HTML o de cómo funciona un servidor de páginas web puedes aprender suficiente código y SQL como para crear tu primera aplicación en una tarde. Es bastante simple una vez entiendes cómo funciona.

Básicamente creas tu base de datos, la enlazas con el servidor por ODBC o similar, y creas tus páginas .CFM que contienen código HTML y funciones de acceso a la base de datos. Normalmente las páginas son o bien para introducir datos (formularios, como en Access), o bien para mostrarlos (como las consultas e informes de Access).

japbcn escribió:

Visual Basic 2010 es el que me ha parecido mas adecuado ya que tendrá que actuar en muchos PC que siguen con Windows XP y a los que les costará tiempo cambiar a 64 bits.

La gran ventaja de pasarte a desarrollar tu aplicación como aplicación web es justamente esa, son muy fáciles de actualizar y ampliar, sólo requieren de un navegador y un ordenador muy básico para que los usuarios accedan y pueden hacerlo desde cualquier parte (que tú permitas).

La pregunta es compleja, pero la respuesta lo es mucho más, porque depende de muchísimas cosas que solamente tú conoces...

japbcn escribió:

En mi trabajo estoy haciendo pequeñas aplicaciones para Excel en VBA

VBA es para eso, para pequeñas aplicaciones que hagan 4 virguerías, pero no olvidemos que se trata una aplicación ofimática.

japbcn escribió:

... llevar el control de Stock a partir del fichero enviado por el cliente, control de Stocks ...

Entiendo que usáis Excel como front-end, pero el stock está en una BBDD (o algo parecido como Access)...

japbcn escribió:

He mirado el Visual Studio, pero ahí está el C++, El Visual Basic y otros que no conozco.

En breve me interesará poder "volcar" datos de paginas Web y basicamente tratar los datos, hacer estadisticas, etc...

Visual Basic 2010 es el que me ha parecido mas adecuado ya que tendrá que actuar en muchos PC que siguen con Windows XP y a los que les costará tiempo cambiar a 64 bits.

Por aquí andas algo más perdido....

La versión de Visual Studio, desde la 2003, marca las capacidades de los lenguajes de programación, pero no es tan significativa como para determinar la potencia de la máquina cliente donde corren (el runtime).
Eso viene determinado por la versión del framework .Net que tenga instalada la máquina cliente.

Esto significa que puedes usar Visual Basic 2010 y compilarlo para el Framework 2.0, por ejemplo (tampoco hace falta irse tan lejos, Windows XP soporta el framework 4.0 tranquilamente).

En resumen (y teniendo en cuenta que no sé nada de tu proyecto: volúmen de datos, conectividad, usuarios concurrentes, ... y que todo tiene su parte buena y su parte mala) te diría:

1) Si has de comprar VS, píllate la versión más moderna que permita compilar con Frameworks soportados por Windows XP. Esto afecta a que la máquina de desarrollo deberá ser potente, pero no afecta a las máquinas clientes.
La ventaja es que a medida que las máquinas clientes se modernizan, tú solamente has de variar la versión de compilación.
Por contra, has de tener en cuenta que la versión de compilación determina la versión del lenguaje de programación (hay objetos disponibles para el framework 4.0 que no te compilarán para el framework de la 2.0)

2) Si cambias VBA por un lenguaje serio, yo me decantaría por C#.
Con VB podrás aprovechar código de VBA, pero tampoco mucho porque los objetos serán distintos (a no ser que uses las librerías de Interop Office, pero para mí eso es salir del fuego para irse a las brasas). Además, te conviene hacer un buen diseño OOP que haga tu aplicación más fácil de mantener y rápida de desarrollar.
Con C# tienes la ventaja que si eres capaz de separar bien las tres capas de desarrollo, podrás aprovechar muchas clases para el tratamiento web con ASP.NET.

3) Aprovecha y como dice Nox, migra tus datos a una BBDD seria como MySQL; tienes una versión gratuita y el apoyo de Oracle detrás.

#3

No había visto tu post.

Yo he basado mi respuesta en el supuesto de que le interesa una aplicación con una misma base pero dos front-ends; uno cliente y otro web.
De lo contrario, si sólo fuese web, la versión del sistema operativo del PC cliente le daría igual.

No obstante, si da un vuelco a su conjunto de semi-aplicaciones VBA, recomendarle Access y ODBC no lo veo muy apropiado, porque a la larga terminará encontrándose igual de limitado.

MySQL es claramente una buena apuesta gratuita, si es que no es la mejor.

dj_casero escribió:

No obstante, si da un vuelco a su conjunto de semi-aplicaciones VBA, recomendarle Access y ODBC no lo veo muy apropiado, porque a la larga terminará encontrándose igual de limitado.

Era más por la familiaridad con el VBA, es lo mismo programar sobre Excel que sobre Access. Pero es cierto que las limitaciones son similares.

dj_casero escribió:

MySQL es claramente una buena apuesta gratuita, si es que no es la mejor.

Yo migraría el modelo de la base de datos a MySQL y luego depende de lo que le sea más rápido o sencillo, hacerlo todo con MySQL, usar un frontend web, o incluso seguir accediendo a los datos desde Access o Excel. Todo es posible

¡Vaya! Esto se me había pasado por alto:

klausmaria escribió:

C++ es un lenguaje de nivel más bajo que Visual Basic, para hacer lo mismo necesitas muchísimo más código.

Eso no es cierto: todo depende del conjunto de librerías que tengas a mano....

Sí es cierto que C++ es mucho más complejo y requiere una curva de aprendizaje mayor. Utiliza punteros y debes reservar y liberar memoria de verdad.
Pero tiene muchísimas ventajas, incluyendo la velocidad (si usas un compilador nativo).

En lo que te doy la razón es que en muy contadas ocasiones las ventajas de usar C++ superan a sus desventajas.

Ante todo quiero daros las gracias a todos por vuestras respuestas, que en una gran mayoria me ha ayudado, y en algun caso me he quedado "a cuadros" ya que no domino tanto el lenguaje como para entender corresctamente la respuesta. Pero gracias de verdad.

Creo que uno de los defectos mas importantes, es no explicar correctamente el uso que le voy a dar y eso es importante a la hora de decidir.

A ver: La gran mayoria de nuestros clientes nos suministran un Excel, con todos los datos para realizar sus envios. Yo manipulo estos Excel ya que en algunos casos el nombre viene en dos columnas, la direccion en cuatro o cinco que hay que juntar, la poblacion y el codigo postal juntos que hay que separar, etc...Una vez hecho esto ya puedo ordenar este Excel, añadiendole mas columnas de datos y el resultado se integra en el "Programa madre" de la compañia que es el que se encarga de convertir cada registro en un envio y lanzar las etiquetas.
Algunos me mandan ficheros de texto en vez de Excel.
Por otro lado, tenemos otro grupo de clientes, a los que realizamos la seeccion del material que van a enviar. Nosotros tenemos el material y en una de las columnas de su excel me indican, cada uno de una manera distinta que materiales debemos enviar en cada envio. El proceso para ellos es el mismo, lo que luego me he oganizado otros programas para descomponer estos campos, extraer las referencias y las cantidades y poder traspasarlo a un Libro de excel donde controlos los Stocks.

Luego, el "Programa madre", me suministra informacion de todos los envios del dia, por ejemplo, pudiendolos volcar a Excel, no hay otro opcion de extraer datos de ahí, donde entonces puedo disponer de un "Historico" del dia, que cada dia voy añadiendo a otro Excel para general los informes de la actividad del dia, luego del es, etc..

De ahí que mis inicios hayan sido en VBA, ya que prácticament solo uso Excel.

Pero... vamos creciendo. Digamos que estamos en un promedio de 1.500 registros diarios, lo que conlleva unos Excel historicos para extraer los datos que necesito para los informes de gestion de unos 35.000 registros mensuales.

Y eso para Excel, aunque sigue funcionando perfectamente, empieza a ralentizar el proceso.

Hay que tener presente que estos historicos deben estar activos como por ejemploa para cuando alguien devuelve un pedido, con lo que entro en el modulo de VBA que hice para esto, y solo con el numero de pedido ya me da toda la información del pedido y me repone el stock.

Ahora, aunque ya trabajo com Menus que van saltando de un trabajo a otro, tengo que poner orden en todos los modulos, agruparlos y por eso me planeaba cambiar a otro Sistema.

La idea era saltar de Excel con VBA a...?

Entiendo que lo mas aconsejable sea pasar los datos una vez finalizado el dia a Acces ?

Espero haber podido dar una idea mas clara de mi actividad y mis necesidades.

Muchas gracias a todos.

Vosotros lo que necesitáis es una consultoría para que os haga un análisis de procesos y os seleccionen e instalen algún tipo de ERP.

Así a bote pronto y tirando por lo fácil y barato, se me ocurre un PrestaShop, para que os capture los pedidos vía web, con módulo de impresión de etiquetas para sustituir al programa "madre" (cómo suena eso a la película "Alien" ).

Eso sí, asegúrate de que puedes realizar otras tareas dentro de la empresa, porque tu carga de trabajo se va a reducir en un 95%.

Por favor, olvidaros del tema Web por el momento.

Los Excel me llegan por email.

Y el Programa "madre" que es donde debo volcar la información solo me admite ficheros en Excel o en txt.

Lo de la Web es para un paso posterior que no se va a producir por el momento ya que los que clientes que la utilizan me mandan la información en txt.

Gracias lgarrido por el consejo, pero de momento, y espero que por mucho tiempo, yo soy el que analiza los procesos... (!)

Entendido, alto y claro. Suerte con el Excel y el VBA o lo que elijas.

Yo en conciencia y sin tener más información no puedo recomendarte tanto trabajo manual para vosotros y vuestros clientes, desarrollos a medida y tecnología de los años 90, no lo veo competitivo. Pero a lo mejor la idiosincrasia de vuestra empresa es la solución que demanda.

En tu lugar, utilizaría Visual Basic 2010 Express (con menor curva de aprendizaje dado lo que has estado haciendo hasta ahora y no vas a necesitar más), o incluso Visual Web Developer 2010 Express: te permite hacer una aplicación web para la intranet y programar la lógica tanto en Visual Basic como en C#. Tiene la ventaja de que puedes crear una interfaz de consulta para los usuarios y que estos no tengan que acceder directamente a los ficheros de datos, con todos los riesgos que ello conlleva.
Todos las hojas de cálculo y ficheros de texto con los datos de entrada los volcaría a una BBDD (dado que el volumen ni la concurrencia parece que vayan a ser grandes, te vale con Access). Desde ahí se puede explotar de muchas maneras.

japbcn escribió:

Por favor, olvidaros del tema Web por el momento.

Yo hubiese tirado por ahí, haciendo que los clientes cargasen los pedidos con un formulario estandarizado en lugar de con un Excel. Menos posibilidad de errores, menos trabajo para vosotros, el mismo para el cliente... la clave de la adopción por parte de los clientes es ponérselo fácil y que obtengan algún beneficio de ello.

Pero normalmente esos cambios nunca van tan suaves como parece la gente odia cambiar la forma en que trabaja.

#13

Claro, es mucho menos trabajo para todos, menos posibilidad de error, funcionalidad añadida (lo siento, no tenemos stock de este artículo hasta dentro de tres días) y no requiere del cliente más que un navegador web. Y normalmente estos procesos son bastante estándar, así que es mucho más barato, sencillo y fiable adaptar un software comercial (o libre, pero con amplia base de usuarios y posibilidad de soporte comercial) que desarrollar uno desde cero.

Evidentemente si la clientela son mecánicos de automóvil de 50 años o más no es seguramente una solución adecuada, para ellos lo que necesitas es un telefonista que tome el pedido de viva voz. Pero alguien capaz de rellenar una hoja Excel no deberia tener demasiado problema en rellenar un formulario web.

#8

Ahora entiendo mejor tus requisitos.

Creo que de entrada has de valorar dos cosas:

1) Resultados a corto plazo. Significa una ligera mejora en los resultados con un coste bajo en recursos.
Por contra, tendrás unas limitaciones que pueden saltarte en cualquier momento, o no.

2) Resultados a largo plazo. Das un salto cualitativo a tu entorno, con un coste generalmente alto en recursos.
Esto suele suponer una apuesta de futuro, porque en el fondo estás abonando el terreno para abordar mayores retos.
En este caso, valora si estás dispuesto a asumir un coste que te permita dar un buen servicio en el futuro. Creo que es mucho peor no poder dar un servicio adecuado a 15000 clientes por no estar preparado y que se vayan a la competencia, a no tener ninguno.

En base a esa valoración, puedes tomar dos caminos:
1) La solución fácil pero continuista (seguir con VBA, Visual Basic, Access, ...)

2) La solución escalable, que te permita crecer con cabeza, añadiendo recursos si lo consideras oportuno.

Depende de muchos factores tomar un camino u otro, y en el fondo, como he comentado antes, se trata de una apuesta de futuro.

Si decides dar un salto cualitativo con lo que tienes actual, manteniendo la filosofía de uso pero modificando su arquitectura, yo te recomendaría:


1) Diseña tu BBDD en MySQL.

2) Diseña la capa lógica de acceso a datos, en C#. Esta capa es la que accede a los datos, de manera que si ahora accedes a MySQL y mañana accedes a Oracle (o incluso a Access ) las demás capas no se enteran.

3) Diseña la capa de negocio en C#. Es la que trata de elaborar las rutinas de trabajo que le manda la capa gráfica, accediendo a los datos que le proporciona la capa de datos.

4) Diseña la capa de interfaz gráfica en C#, solicitando a la capa de negocio lo qué debe hacer y cómo.

5) En el futuro, diseña la interfaz web en ASP.NET (C#), accediendo a las mismas capas que la interfaz gráfica.

Ser continuista con Visual Basic no lo veo una solución óptima, porque de entrada deberás aprender a programar en él (aunque sepas VBA comparten la misma estructura de lenguaje, pero dudo mucho que en VBA puedas diseñas tus clases, hacer herencia o diseñar tus propios controles gráficos).
Y para continuar, pierdes mucha opción de reaprovechar tu código en una futura adaptación web, teniendo que coexistir ambas (la cliente PC con la web).