Pasar proyecto a instalador [Delphi]

Hola gente del foro en esta ocasión voy  preguntar como pasar un proyecto de delphi a archivo instalador

y otra pregunta que voy hacer es cuales son los  problemas mas frecuentes que puede tener el cliente(en caso que el programa falle ). 

Espero que me puedan ayudar.

Gracias 

Hola gente del foro en esta ocasión voy  preguntar como pasar un proyecto de delphi a archivo instalador
y otra pregunta que voy hacer es cuales son los  problemas mas frecuentes que puede tener el cliente(en caso que el programa falle ). 
Espero que me puedan ayudar.
Gracias

Hola amigo the warlus,

Delphi no funciona como Visual  Studio que genera un programa instalador desde su IDE.

Anteriormente Delphi se distribuia con un generador de instaladores externo llamado InstallShield pero dejo de distribuirlo, no recuerdo desde que versión.

Puedes utilizar el más común llamado Inno Setup para generar tus instaladores.

En cuanto a la otra pregunta no entiendo si hablas del instalador o del programa, en todo caso hay muchas razones por las que puede fallar una aplicación.

Saludos

Hola amigo the warlus,

 

Delphi no funciona como Visual  Studio que genera un programa instalador desde su IDE.

 

Anteriormente Delphi se distribuia con un generador de instaladores externo llamado InstallShield pero dejo de distribuirlo, no recuerdo desde que versión.

 

Puedes utilizar el más común llamado Inno Setup para generar tus instaladores.

 

En cuanto a la otra pregunta no entiendo si hablas del instalador o del programa, en todo caso hay muchas razones por las que puede fallar una aplicación.

 

Saludos

Hola egostar gracias por tu respuesta también te quería pregunta aparte del proyecto y la base de datos que otro archivo requiere para poder generar el instalador

y con respecto a la otra pregunta me refería cuando la aplicación  empieza a tener ciertos fallos en la pc del cliente(soy nuevo en esto).

Saludos    

Hola egostar gracias por tu respuesta también te quería pregunta aparte del proyecto y la base de datos que otro archivo requiere para poder generar el instalador

A diferencia de otros leguajes que requieren librerias externas, con Delphi solo necesitas el ejecutable (archivo .exe) y la base de datos (incluye drivers de conexión), puede ser que necesites un archivo INI para la configuración de la conexión a la base de datos que sería lo más normal y listo, ya tienes todo lo necesario para que funcione tu aplicación.
 

y con respecto a la otra pregunta me refería cuando la aplicación  empieza a tener ciertos fallos en la pc del cliente(soy nuevo en esto).
Saludos

Eso es dificil de preveer y se tendrá que ver caso por caso, normalmente los "fallos" son por cosas no previstas o por una mala práctica al codificar.

Los "errores" más comunes que te pudieras enfrentar es por conexiones a la base de datos o por cuestiones de seguridad, por ejemplo antivirus o firewall que bloquean algunas operaciones en los programas.

Saludos

Hola gente del foro en esta ocasión voy  preguntar como pasar un proyecto de delphi a archivo instalador

y otra pregunta que voy hacer es cuales son los  problemas mas frecuentes que puede tener el cliente(en caso que el programa falle ). 

Espero que me puedan ayudar.

Gracias 

Por lo del tema de generar el instalador no voy a comentar porque ya te han estado sugiriendo.

Ahora respecto a lo último que dices, sobre los fallos... quisiera que se me permita decir unas palabras. Advierto de que posiblemente no sea "políticamente correcto" como voy a sonar. En el foro se me conoce por ser un poco "chingón" o "tira orejas".

Lo fundamental es que: ¡No hay software que no tenga fallos! Partamos de esa base. Todos software está roto, algunos más que otros pero todos. Aquel que diga con demasiada liviandad de que es capaz de hacer software 100% libre de fallos y es 100% seguro está mintiendo.

Asi que lo peor que puedes hacer es vender software con demasiado marketing de que tu software esta libre de ellos.

Ahora que te curaste de ser un comercial que sería capaz de vender a su abuela o a su madre con tal de ganar plata, deberás pensar que posturas tendrás cuando surjan los problemas.

Yo las resumo en 4 opciones:

1. Hacerte el estúpido como que nada ha pasado y no darle el más mínimo interés en solucionarlo.

2. Asumir que no eres perfecto. Dar la cara. Mentirle al usuario que ves el tema y no resolverlo.

3. Asumir la responsabilidad. Poner un plazo de cuanto estará listo por resolver.

4. Ponerse la vida en serio, y ofrecer un buen área de soporte.

Lo mejor es el 4to punto. Ya hablaré de eso. El pto 3 no es tan malo... pero es quizá el más tentador con vista a calmar al cliente enojado. "Dejame que lo vea, y te prometo que en x días estará listo" Si en X días no lo resuelves ¡cuidado! porque acabas de convertirte en el punto 2,  y para el cliente estarás en el punto 1.

La lección es que si vas a hacer software, en la misma forma y con la misma o incluso más enegía, deberás estar dispuesto a dar adicionalmente un servicio de atención. Cómo lo encares no es nuestra función el decirte. El compañero Egostar te diría "Depende, depende". Y si, depende de mil variables: de tu cercanía con tus clientes, de tus disponibilidades técnicas-operativas, de tus propios conocimientos y limitaciones. El servicio puede ser muy personalizado a cada cliente, o algo genérico que pueda ser aplicado a muchos...

No hay receta que te diga esto se hace así y mágicamente las cosas resultan. Hay clientes que ante el más mínimo defecto que no altera el procedimiento crítico del sistema y es algo "estético" llaman enfurecidos diciendo que el software no anda. Y hay otros que son más tratables. Asi que eso lo irás desarrollando a medida que te vayan llegando las llamadas, los tickets de servicio, o mails, mensajes, o el medio de contacto que tu hayas dispuesto.

Aún así las buenas prácticas de la Ingeniería de Software sugieren:

1. Documentar. Si es una mierda, aburridísimo pero documenta tu software. El día de mañana lo vas a agradecer cuando las papas quemen. La doc no es sólo es código. Implica documentar el proyecto mismo. Que se hace, cuando, porqué, cómo. Que fallos se han estado produciendo durante el desarrollo, las pruebas realizadas, TODO. Cuanto más registres más será de ayuda.

2. Lleva un control de incidencias. Ya sea que lo hagas manual o te apoyes en alguna herramienta. Esto debe acompañar también a la documentación.

3. Por el amor a Robert Pressman y Craig Larman, ¡Has Pruebas! ¡Pruebas y más pruebas! Si... es otra mierda, y nunca son suficientes, pero destina esfuerzo en probar tu sofware. No te apresures en lanzarlo, mejor trágate tu orgullo y date tiempo en reventar tu creación. Duele, lo se... pero es así la cosa. Hay que probar primero antes de publicar.

Ya con esto creería que te imaginas:

A. Mandar a la mierda lo que te digo.

B. A ver, si me lo dice es por algo, vale, me siento y me lo tomo en serio.

Si optas por A. ¡Buena suerte! Y si optas por B, ¡También! ¡Buena suerte!

¿Quieres hacer software? Buenísimo. Hazlo. Pero déjame decirte que la era de la factoría de software al estilo Henry Ford que saca mil copias ya pasó. Ahora el poder de un negocio no está en vender mil licencias. Sino en el agregado que tu le des al software. Un servicio post-venta, uno de soporte, uno que acompañe al cliente en los problemas. que lo guíe en su trabajo, que lo asista. En resumen: Si tus clientes crecen, tu creces.

Ahora de nuevo, te pregunto. ¿Que eres? ¿Que haces? ¿Que vendes? Entonces... ¿Que vas a hacer (o mejor dicho: dispuesto a hacer) para responderte a esas tres preguntas?

No más para decir señor juez. Con esta tirada de orejas me despido.

Saludos,

A diferencia de otros leguajes que requieren librerias externas, con Delphi solo necesitas el ejecutable (archivo .exe) y la base de datos (incluye drivers de conexión), puede ser que necesites un archivo INI para la configuración de la conexión a la base de datos que sería lo más normal y listo, ya tienes todo lo necesario para que funcione tu aplicación.
 

 

Eso es dificil de preveer y se tendrá que ver caso por caso, normalmente los "fallos" son por cosas no previstas o por una mala práctica al codificar.

 

Los "errores" más comunes que te pudieras enfrentar es por conexiones a la base de datos o por cuestiones de seguridad, por ejemplo antivirus o firewall que bloquean algunas operaciones en los programas.

 

Saludos

Como base de datos utilizo MS Access que driver me recomendarías.

Saludos. 

Por lo del tema de generar el instalador no voy a comentar porque ya te han estado sugiriendo.

Ahora respecto a lo último que dices, sobre los fallos... quisiera que se me permita decir unas palabras. Advierto de que posiblemente no sea "políticamente correcto" como voy a sonar. En el foro se me conoce por ser un poco "chingón" o "tira orejas".

 

Lo fundamental es que: ¡No hay software que no tenga fallos! Partamos de esa base. Todos software está roto, algunos más que otros pero todos. Aquel que diga con demasiada liviandad de que es capaz de hacer software 100% libre de fallos y es 100% seguro está mintiendo.

Asi que lo peor que puedes hacer es vender software con demasiado marketing de que tu software esta libre de ellos.

Ahora que te curaste de ser un comercial que sería capaz de vender a su abuela o a su madre con tal de ganar plata, deberás pensar que posturas tendrás cuando surjan los problemas.

 

Yo las resumo en 4 opciones:

1. Hacerte el estúpido como que nada ha pasado y no darle el más mínimo interés en solucionarlo.

2. Asumir que no eres perfecto. Dar la cara. Mentirle al usuario que ves el tema y no resolverlo.

3. Asumir la responsabilidad. Poner un plazo de cuanto estará listo por resolver.

4. Ponerse la vida en serio, y ofrecer un buen área de soporte.

 

Lo mejor es el 4to punto. Ya hablaré de eso. El pto 3 no es tan malo... pero es quizá el más tentador con vista a calmar al cliente enojado. "Dejame que lo vea, y te prometo que en x días estará listo" Si en X días no lo resuelves ¡cuidado! porque acabas de convertirte en el punto 2,  y para el cliente estarás en el punto 1.

 

La lección es que si vas a hacer software, en la misma forma y con la misma o incluso más enegía, deberás estar dispuesto a dar adicionalmente un servicio de atención. Cómo lo encares no es nuestra función el decirte. El compañero Egostar te diría "Depende, depende". Y si, depende de mil variables: de tu cercanía con tus clientes, de tus disponibilidades técnicas-operativas, de tus propios conocimientos y limitaciones. El servicio puede ser muy personalizado a cada cliente, o algo genérico que pueda ser aplicado a muchos...

 

No hay receta que te diga esto se hace así y mágicamente las cosas resultan. Hay clientes que ante el más mínimo defecto que no altera el procedimiento crítico del sistema y es algo "estético" llaman enfurecidos diciendo que el software no anda. Y hay otros que son más tratables. Asi que eso lo irás desarrollando a medida que te vayan llegando las llamadas, los tickets de servicio, o mails, mensajes, o el medio de contacto que tu hayas dispuesto.

 

Aún así las buenas prácticas de la Ingeniería de Software sugieren:

1. Documentar. Si es una mierda, aburridísimo pero documenta tu software. El día de mañana lo vas a agradecer cuando las papas quemen. La doc no es sólo es código. Implica documentar el proyecto mismo. Que se hace, cuando, porqué, cómo. Que fallos se han estado produciendo durante el desarrollo, las pruebas realizadas, TODO. Cuanto más registres más será de ayuda.

2. Lleva un control de incidencias. Ya sea que lo hagas manual o te apoyes en alguna herramienta. Esto debe acompañar también a la documentación.

3. Por el amor a Robert Pressman y Craig Larman, ¡Has Pruebas! ¡Pruebas y más pruebas! Si... es otra mierda, y nunca son suficientes, pero destina esfuerzo en probar tu sofware. No te apresures en lanzarlo, mejor trágate tu orgullo y date tiempo en reventar tu creación. Duele, lo se... pero es así la cosa. Hay que probar primero antes de publicar.

 

Ya con esto creería que te imaginas:

A. Mandar a la mierda lo que te digo.

B. A ver, si me lo dice es por algo, vale, me siento y me lo tomo en serio.

 

Si optas por A. ¡Buena suerte! Y si optas por B, ¡También! ¡Buena suerte!

¿Quieres hacer software? Buenísimo. Hazlo. Pero déjame decirte que la era de la factoría de software al estilo Henry Ford que saca mil copias ya pasó. Ahora el poder de un negocio no está en vender mil licencias. Sino en el agregado que tu le des al software. Un servicio post-venta, uno de soporte, uno que acompañe al cliente en los problemas. que lo guíe en su trabajo, que lo asista. En resumen: Si tus clientes crecen, tu creces.

 

Ahora de nuevo, te pregunto. ¿Que eres? ¿Que haces? ¿Que vendes? Entonces... ¿Que vas a hacer (o mejor dicho: dispuesto a hacer) para responderte a esas tres preguntas?

 

No más para decir señor juez. Con esta tirada de orejas me despido.

 

Saludos,

Si ese es el punto, estar a disposición del cliente en cuanto a soporte. 

La idea  no es  hacerse unos pesos y luego desentenderse por completo, y con respecto a las fallas que mencionaba no me refería que al cliente no le guste algunas funciones  o no le guste el software del todo  si no cuando el mismo acude al soporte técnico y dice la palabra mágica " no hay sistema ".

Como dije anteriormente soy nuevo en esto y si te preguntas ¿por que haces estas preguntas tan tonta? respondería que  desconozco como hacerlo.

Lo único que me queda por decir perdón por ser un completo ignorante.

Saludos.       

Como base de datos utilizo MS Access que driver me recomendarías.

Con Access deberías utilizar los componentes ADO que están en la paleta de componentes, hasta donde sé (Que Caral me corrija) utiliza conexiones ODBC.
 

Como dije anteriormente soy nuevo en esto y si te preguntas ¿por que haces estas preguntas tan tonta? respondería que  desconozco como hacerlo.
Lo único que me queda por decir perdón por ser un completo ignorante.

Bueno, no es una pregunta "tonta", es una pregunta normal cuando no conoces algo y como dice el dicho por acá, "Preguntando se llega a Roma".

No te disculpes, nuestro amigo Delphius es un maestro de la "vieja guardia" y lo dice con el mejor de los ánimos

Saludos

No es mi intención ofenderte Walrus, y no pienso que la pregunta sea tonta.

Lo que espero con mis respuestas es justamente sacudir a los iniciados y despertarles la seriedad en como debe encararse el desarrollo de software.

He dicho algunas veces en el foro que el desarollo de un software es como estar en etapa de noviazgo, todo es bello, estamos muy enamorados de nuestra creación. En cuanto la liberamos, ya no es noviazgo es un casamiento.

Si, lo afirmo, en el momento en que publicas tu software te casas con él. Ahora eres responsable de su seguridad, debes mantenerlo, cuidarlo, estar atento a sus mimos, a sus carpichos.

No es que "sales a vender y vas a dar soporte". No. Stop. Frena. Piensa, y arma un buen plan de como y que vas a incluir en el soporte. No sólo como mirada profesional sino como forma de trabajo real, a consciencia. Y buen tacto humano.

No apunto a que al cliente no le agrade alguna función, porque convengamos en que si adquiere la licencia es porque ha visto en el software algo que le atrae y le parece útil.

En mi experiencia y en el trato con varios clientes puedo decirte que hay varios tipos de especímenes. Está el tipo más tranquilo y algo más formado que entiende que el desarrollo de software es un proceso delicado, y en el otro extremo hay quienes no son capaces de entender que el sofware puede fallar (y fallará, tarde... o temprano) y son muy temperamentales y quieren una solución para antes de ayer, pero que te van a avisar del problema mañana.

Y así es como ellos, quieras o no, te van a encasillar en alguna de las 4 posturas que he descripto en mi anterior post. Y en función de eso se irá desarrollando tu relación con los clientes.

Lo de "no hay sistema" es una palabra que los clientes odian. En lo posible hay que evitar emplearlas, y lo mejor es ir entrenándolos para que cuando te vayan a reportar un problema lo hagan de forma correcta. La mayoría te va a decir: "no funciona", "no hay sistema", "no imprime", "no X". Deberás tener paciencia y tacto para ir guiándolos con preguntas, y repreguntas, sobre que estaba haciendo, o que quiso hacer, que intentó, que describa los pasos, que te diga que error leyó, cuando, donde, etc.

El "no hay sistema" es tan variado... puede ser que se desconectó la red, o que no hay internet (si depende de ello), o que equipo servidor se apagó/fundió, se reinició el equipo, o cayó el servicio que mantiene al servidor de base de datos funcionando... es tan amplio, y no puedes estar perdiendo el tiempo como para ir adivinando donde está el problema. Es un trabajo que deben hacer ambos. A veces se puede hacer asistencia remota, y en otras... no queda otra que hacer presencia.

Es verdad que al cliente poco le importa el detalle técnico, quiere solución, y la quiere ya, o para ayer. Pero para una sana convivencia con él ambos deberán aprender a desarrollar un lenguaje y saber diagnosticar por donde puede venir la falla.

Por ejemplo, te cuento un caso que se ha dado el día de hoy en mi trabajo. A un cliente le sale un cartel de "La memoria fiscal de la impresora está casi llena". El cliente nos llama un tanto preocupado por no saber que significaba. Se le infoma que la impresora debe ser enviada al soporte técnico certificado por la AFIP (el organismo que regula la actividad Fiscal en Argentina, mi país) ya que internamente el contador de comprobantes emitidos está casi al límite y no es un fallo de sistema. Se queda tranquilo y se pone en contacto con el servicio técnico homologado. Ese nivel de comunicación ha llevado 2 años de lograrlo. Antes simplemente nos decía "El sistema no imprime. Arreglalo", cortaba y teníamos que volver a llamar para sacarle algo de información.

¿Es un problema mio? ¿El sistema dejó de andar? ¡No! Entonces hay que separar los tantos. Y deberás tener la firmeza pero también la delicadeza ante casa caso. Tenemos otro cliente en el cual una usuaria ha sufrido un ACV. De vez en cuando ella nos llama para preguntarnos como se hacía X cosa. Mi compañero de trabajo ha desarollado mucha paciencia para explicarle tantas veces lo mismo.

Y tenemos otro cliente muy temperamental que se cree amo y señor y que estaremos las 24x7 a su servicio y somos sus esclavos. Lleva años usando los servicios, y aún asi se resiste. Su actitud es tal que con él nos lleva a escuchar su sermonería, decirle que si a todo, pero por dentro hacer medios sordos, esperar que corte la llamada. Y luego comunicarnos con su personal para traducir el problema.

El soporte es más que "ir a arreglarlo, y ya está". Es todo un proceso que hace LA CARA VISIBLE de tu emprendimiento. Por lo que no sólo debe lucirse bien, sino que debe hacerse bien.

No lo tomes a la ligera. Analiza bien. Define como va a ser tu plan de servicio, hasta donde estás en posicición de dar soporte. Arma un plan de contingencia, ten políticas de respaldo, lleva defensiva. Busca predecirte a los problemas antes que surjan. Si un cliente te llama por un problema, no esperes a que otro también lo haga. Y si te caen mil llamadas por varios problemas que parecen aislados... uff... mejor somete a una sirugía a tu sofware que algo raro tiene.

A veces la ausencia de un diagnóstico de que es lo que tiene, se convierte en el diagnóstico.

Saludos,

No te disculpes, nuestro amigo Delphius es un maestro de la "vieja guardia" y lo dice con el mejor de los ánimos

 

Saludos

¿Vieja guardia? A ver compadre... ¿que me ha querido decir?    ¡No me sume años, ya bastante sufro con que por mi barba la gente me sume 10! Usted utilizó tarjetas perforadas y yo no digo nada... ¡pero che!    

Saludos,

No es mi intención ofenderte Walrus, y no pienso que la pregunta sea tonta.

Lo que espero con mis respuestas es justamente sacudir a los iniciados y despertarles la seriedad en como debe encararse el desarrollo de software.

 

He dicho algunas veces en el foro que el desarollo de un software es como estar en etapa de noviazgo, todo es bello, estamos muy enamorados de nuestra creación. En cuanto la liberamos, ya no es noviazgo es un casamiento.

Si, lo afirmo, en el momento en que publicas tu software te casas con él. Ahora eres responsable de su seguridad, debes mantenerlo, cuidarlo, estar atento a sus mimos, a sus carpichos.

 

No es que "sales a vender y vas a dar soporte". No. Stop. Frena. Piensa, y arma un buen plan de como y que vas a incluir en el soporte. No sólo como mirada profesional sino como forma de trabajo real, a consciencia. Y buen tacto humano.

 

No apunto a que al cliente no le agrade alguna función, porque convengamos en que si adquiere la licencia es porque ha visto en el software algo que le atrae y le parece útil.

 

En mi experiencia y en el trato con varios clientes puedo decirte que hay varios tipos de especímenes. Está el tipo más tranquilo y algo más formado que entiende que el desarrollo de software es un proceso delicado, y en el otro extremo hay quienes no son capaces de entender que el sofware puede fallar (y fallará, tarde... o temprano) y son muy temperamentales y quieren una solución para antes de ayer, pero que te van a avisar del problema mañana.

Y así es como ellos, quieras o no, te van a encasillar en alguna de las 4 posturas que he descripto en mi anterior post. Y en función de eso se irá desarrollando tu relación con los clientes.

 

Lo de "no hay sistema" es una palabra que los clientes odian. En lo posible hay que evitar emplearlas, y lo mejor es ir entrenándolos para que cuando te vayan a reportar un problema lo hagan de forma correcta. La mayoría te va a decir: "no funciona", "no hay sistema", "no imprime", "no X". Deberás tener paciencia y tacto para ir guiándolos con preguntas, y repreguntas, sobre que estaba haciendo, o que quiso hacer, que intentó, que describa los pasos, que te diga que error leyó, cuando, donde, etc.

El "no hay sistema" es tan variado... puede ser que se desconectó la red, o que no hay internet (si depende de ello), o que equipo servidor se apagó/fundió, se reinició el equipo, o cayó el servicio que mantiene al servidor de base de datos funcionando... es tan amplio, y no puedes estar perdiendo el tiempo como para ir adivinando donde está el problema. Es un trabajo que deben hacer ambos. A veces se puede hacer asistencia remota, y en otras... no queda otra que hacer presencia.

Es verdad que al cliente poco le importa el detalle técnico, quiere solución, y la quiere ya, o para ayer. Pero para una sana convivencia con él ambos deberán aprender a desarrollar un lenguaje y saber diagnosticar por donde puede venir la falla.

 

Por ejemplo, te cuento un caso que se ha dado el día de hoy en mi trabajo. A un cliente le sale un cartel de "La memoria fiscal de la impresora está casi llena". El cliente nos llama un tanto preocupado por no saber que significaba. Se le infoma que la impresora debe ser enviada al soporte técnico certificado por la AFIP (el organismo que regula la actividad Fiscal en Argentina, mi país) ya que internamente el contador de comprobantes emitidos está casi al límite y no es un fallo de sistema. Se queda tranquilo y se pone en contacto con el servicio técnico homologado. Ese nivel de comunicación ha llevado 2 años de lograrlo. Antes simplemente nos decía "El sistema no imprime. Arreglalo", cortaba y teníamos que volver a llamar para sacarle algo de información.

¿Es un problema mio? ¿El sistema dejó de andar? ¡No! Entonces hay que separar los tantos. Y deberás tener la firmeza pero también la delicadeza ante casa caso. Tenemos otro cliente en el cual una usuaria ha sufrido un ACV. De vez en cuando ella nos llama para preguntarnos como se hacía X cosa. Mi compañero de trabajo ha desarollado mucha paciencia para explicarle tantas veces lo mismo.

Y tenemos otro cliente muy temperamental que se cree amo y señor y que estaremos las 24x7 a su servicio y somos sus esclavos. Lleva años usando los servicios, y aún asi se resiste. Su actitud es tal que con él nos lleva a escuchar su sermonería, decirle que si a todo, pero por dentro hacer medios sordos, esperar que corte la llamada. Y luego comunicarnos con su personal para traducir el problema.

 

El soporte es más que "ir a arreglarlo, y ya está". Es todo un proceso que hace LA CARA VISIBLE de tu emprendimiento. Por lo que no sólo debe lucirse bien, sino que debe hacerse bien.

No lo tomes a la ligera. Analiza bien. Define como va a ser tu plan de servicio, hasta donde estás en posicición de dar soporte. Arma un plan de contingencia, ten políticas de respaldo, lleva defensiva. Busca predecirte a los problemas antes que surjan. Si un cliente te llama por un problema, no esperes a que otro también lo haga. Y si te caen mil llamadas por varios problemas que parecen aislados... uff... mejor somete a una sirugía a tu sofware que algo raro tiene.

A veces la ausencia de un diagnóstico de que es lo que tiene, se convierte en el diagnóstico.

 

Saludos,

Hola Delphius gracias por el  consejos y también por despejar mi duda.

Saludos 

¿Vieja guardia? A ver compadre... ¿que me ha querido decir?    ¡No me sume años, ya bastante sufro con que por mi barba la gente me sume 10! Usted utilizó tarjetas perforadas y yo no digo nada... ¡pero che!  

 

Saludos,

No, no lo digo en el sentido de que seas un viejo, lo que digo es que eres de esos "teachers" que aún se preocupan por el alumno aunque sus métodos no son suavecitos (como los de la vieja guardia).

Ahora los pobres maestros no pueden ni levantarle la voz al alumno so pena de ser despedidos si el alumno y/o los padres se quejan de maltrato.

Saludos

   

 

No, no lo digo en el sentido de que seas un viejo, lo que digo es que eres de esos "teachers" que aún se preocupan por el alumno aunque sus métodos no son suavecitos (como los de la vieja guardia).

 

Ahora los pobres maestros no pueden ni levantarle la voz al alumno so pena de ser despedidos si el alumno y/o los padres se quejan de maltrato.

 

Saludos

En la secundaria tenía un profe de Matemáticas que cuando se enojaba con un alumno tiraba la tiza al tacho de basura con bronca. Yo me decía que el día en que le tire a la cabeza a uno se le arma tremendo quilombo.

Yo no se si podría controlar la bronca.

Yo si soy un poco de la vieja escuela, lo admito.

Por cosas de la vida, no he podido ejercer la docencia... Hoy me pregunto si no habrá sido por el bien o mal mio, y/o de los chicos de hoy en día.

Si bien tengo mi título habilitado por la Junta Calificadora (el organismo que se encarga de controlar a los profesores y maestros) para ejercer como docente auxiliar, me ha faltado un detalle importante: Cursar pedagía. En aquel entonces cuando presenté mis papeles a la Junta, y habiendo elegido 6 Escuelas e Institutos (3 y 3 respectivamente) en los cuales pretendía dictar clases no me habían comentado de ese requisito. Así que la idea de enseñar Programación, Estructuras de Datos y Algoritmos, Bases de Datos y Tecnología de la Información quedó "truncada".

Me enteré tarde, cuando presentando mi CV en un Instituto Privado para dictar clases ¡y con Delphi encima! me comentaron de que no tenía registrado ese curso. Me queda la duda si fue un error de la Junta en no avisarme, o si fue a propósito... Hay mano pesada en la Junta que hace lo que se de la gana... Como será la cosa que al día de hoy hay un quilombo bárbaro por asignaciones de titulares con títulos truchos y otras cosas más.

Saludos,

Con Access deberías utilizar los componentes ADO que están en la paleta de componentes, hasta donde sé (Que Caral me corrija) utiliza conexiones ODBC.

Instale mi aplicación en mi pc y funciona perfectamente probé en otra (maquina virtual) con windows xp aquí tengo un problema al ejecutarla me aparece un mensaje " Error de disco o de red" luego de ese mensaje se abre la aplicación las grillas de los formularios están en blanco por completo y cuando quiero ejecutar una acción(borrar un registro )  que  me aparce el mismo mensaje que anteriormente mencione.

Como me dijiste  anteriormente de la conexión  ODBC  necesito un driver (¿archivo que necesito descargar ?) o establecer la conexion por medio de herramientas administrativas de windows.

Para terminar la aplicacion no es cliente servidor.

Saludos.  

Instale mi aplicación en mi pc y funciona perfectamente probé en otra (maquina virtual) con windows xp aquí tengo un problema al ejecutarla me aparece un mensaje " Error de disco o de red" luego de ese mensaje se abre la aplicación las grillas de los formularios están en blanco por completo y cuando quiero ejecutar una acción(borrar un registro )  que  me aparce el mismo mensaje que anteriormente mencione.

Como me dijiste  anteriormente de la conexión  ODBC  necesito un driver (¿archivo que necesito descargar ?) o establecer la conexion por medio de herramientas administrativas de windows.

Para terminar la aplicacion no es cliente servidor.

Saludos.  

Habría que ver como estás armando la conexión hacia la DB. Lo más probable es que el problema esté en la configuración de la conexión. En tu equipo debe funcionar ya que estás apuntando a una DB existe y por consiguiente la ruta existe.

Al distribuir tu aplicación la ruta debe hacerse de forma dinámica y/o relativa a la ubicación que esté el ejecutable en los equipos de tus clientes. Si en tu proyecto tenías algo como "D:\Proyecto\DB\basededatos.mdbx" y la llevas a otro equipo obviamente no va a funcionar a menos que exista esa ruta.

Por ello es que se aconseja seriamente disponer de un archivo de configuración .ini el cual se abre al inicio del programa para recuperar los parámetros y valores de conexión necesarios a fin de armar la conexión. Lo más fácil es que el ejecutable busque la DB en el mismo directorio en el cual está ubicado, o en un subdirectorio de éste, pero esto no es estrictamente necesario. La DB puede estar en cualquier otro lado. Lo importante es que tengas almacenado de forma persistente (.ini, registro de Windows, o archivo propio) o bien buscar en la ruta relativa en donde se encuentra el ejecutable.

En principio no hace falta que instales nada ya que en el ejecutable suele ir todo lo necesario. Además ODBC + JET4 viene instalado en los equipos Windows por defecto. Lo que si deberías tener presente es que al ser Access, éste tiene sus limitaciones. Las archivos en Access no pueden superar de cierto tamaño, y el motor JET4 (lo que es en realidad el motor de base de datos, Access es sólo una fachada que interactúa con éste por medio de ODBC) no está preparado para operaciones de alta demanda, acceso recurrente y muchas de las cosas que caracterizan a un verdadero motor de base de datos que se precie.

Yo te recomendaría que más temprano que tarde mires otras opciones, Firebird, MySQL, PostreSQL, Maria DB, MS SQL Server, Oracle por mencionar algunas. Recomiendo, como muchos del foro, a Firebird.

Saludos,

Hice un archivo .ini tal cual como lo hizo Caral en este post http://delphiaccess....vo-ini-novatos/ pero aun asi tengo el mismo problema que mencione no puedo eliminar registros ni tampoco hacer altas