DUDAS sobre Crystal Report y VB for Aplication
Hola, quisiera aprovechar la oportunidad para formular varias preguntas, si me lo permite, que son dudas que tengo y en otros casos cosas que no s茅 como hacerlas.
De antemano le estoy muy agradecido y en lo que le pueda ayudar, que est茅 a mi alcance, pues sin duda lo har茅.
Preguntas (IMPORTANTE --> Trabajo con Visual Basic 5.0 y Crystal Report 4.5)
===========================================================
1) Resulta que tengo un reporte que por cuestiones de ahorro de papel me he visto en la obligaci贸n de mostrar sus datos con Fuente: Arial Narrow = 8, de esta manera, en la pantalla la informaci贸n es impsoible de leer pero cuando se manda a imprimir, todo sale muy bien, o sea, con tama帽o 8 y muy legible.
Entonces mi pregunta est谩 en que si es posible mostrar en pantalla el reporte a un porciento mayor (150%, 200%) tal y como se hace con Word para resolver el problema de poder leer sus datos y luego cuando se imprima pues lo haga en el porciento que trae por defecto en tiempo de dise帽o.
2) Necesito mostrar un reporte en formato .RTF (o Word) utilizando las propiedades correspondientes al ActiveX del Crystal Report: .PrintFileName = "Nombre del fichero", .PrintFileType = crptRTF, .Destination = crptToFile; resulta que todo est谩 bien hasta que trato de hahacerle el .PrintReport que me da un error de automatizaci贸n de esos que uno no sabe ni por qu茅 suceden. Lo curioso es que a pesar de este error el proceso de export谩rmelo funciona, lo 煤nico que ah铆 mismo me da el error.
Si comienzo a trasear el c贸digo, cuando llego a la instrucci贸n:
Res% = F_Main.CrystalReport1.PrintReport, me genera dicho error, que adem谩s no se puede interceptar si continuo con la pr贸xima l铆nea y vuelvo a intentar listarlo pues en la variable Res% me devuelve el numero:
20520 -->> El trabajo de impresi贸n ya ha empezado. Est谩 intentando iniciar un trabajo de impresi贸n que ya est谩 iniciado. Esto puede suceder cuando el usuario inicia un trabajo de impresi贸n y lo quiere volver a imprimir antes de que haya terminado el anterior.
Ahora bien cuando hago la misma operaci贸n con cualquier otro reporte, me funciona sin problemas. Cabe se帽alar que este que trato de exportar tiene un dise帽o un poco complicado, es una Factura, con Logo de la empresa incluido, etc, etc
Adem谩s el reporte que intento exportar a Word cuando lo muestro .Destination = crptToWindow o crptToPrinter todo funciona muy bien.
3) Estoy haciendo una alpicaci贸n en la cual necesito imprimir en un docuento Word los datos provenientes de una BD Access 97, todo m谩s que sencillo, todo me funciona bien, a este docuento Word le cree una Correspondencia con la Base de Datos y todo est谩 perfecto, inserto en el mismo los campos de los cuales deseo mostrar sus datos y todo funciona bien. Pero resulta que este documento lo llamo desde el Visual Basic y el origen de los datos es una tabla que genero en tiempo de corrida y a partir de varias consultas, o sea, que he tenido que correr una Macro de conexi贸n a la base de datos para cojer el c贸digo que genera la misma e insertarlo en el c贸digo del programa mio, m谩s cuando el camino de este programita as铆 como de la fuente de datos no es fijo, es a elecci贸n del cliente, por supuesto que esta macro la elimin茅 del documento pues no me sirve para nada. Pero de todas maneras el problema no est谩 en nada de lo que escrito, todo esto ha sido una intoducci贸n, adem谩s cosa que usted conoce, el PROBLEMA GRAVE EST脕 en que esta base en Access tiene PASSWORD y cuando esto sucede ya la cosa cambia, o sea, cuando tratas de crear la Macro y est谩s en el proceso de abrir el origen de datos en la creaci贸n de la correspondencia, esta te pide el password de la BD todo muy bien, pero cuando miras el c贸digo generado por dicha Macro, ese password no aparece por ning煤n lado y por ende cuando intentas abrir desde tu aplicaci贸n el documento Word, para este mostrar los datos insertados en el documento pues te pide EL PRECIADO PASSWORD. Est谩 de m谩s decirle lo que tuve que hacer, cosa que no me ha gustado ni un poquitico pues es un invento macabro, me he visto en la obligaci贸n de crear una base vac铆a, SIN PASSWORD, y que tenga vinculada la tabla de aquella, CON PASSWROD, para que entonces se pueda conectar el .DOC a esta BD sin problemas y mostrar los datos correspondientes.
Por favor c贸mo resolver este PROBLEMA de pasar la conexi贸n del .DOC a la BD y que esta tenga alg煤n Password ????
Cadena de Conexi贸n:
=================
.OpenDataSource Name:= _
App.Path & "AplicarInstrumento.mdb", ConfirmConversions:=False, ReadOnly:=False, LinkToSource:=True, AddToRecentFiles:=False, _
PasswordDocument:="", PasswordTemplate:="", WritePasswordDocument:="", WritePasswordTemplate:= _
"", Revert:=False, Format:=wdOpenFormatAuto, Connection:="TABLE Tmp_AplicacionInstrumento_I", _
SQLStatement:="SELECT * FROM [Tmp_AplicacionInstrumento_I]", SQLStatement1:=""
4) Algo que tiene que ver con esto de la cadena de conexi贸n de un .DOC a una BD y es que esta Aplicaci贸n la tengo instalada en una empresa donde hay varias PC y, as铆 mismo, diferentes sistemas operativos, o sea, 98 con Office 97 y XP con Office 2k3, yo donde estoy desarrollando la aplicaci贸n tengo la primera de las variantes, as铆 es que en las m谩quinas donde est谩 configurado igual, en la empresa, no me da ning煤n tipo de problema; peroooooooo, cuando es Office 2003 ya la cosa explota, porque la cadena de conexi贸n es otra, o sea, de esto me di cuenta porqie llev茅 los fuentes para aquella empresa y corr铆 por trazas el programa, hice una Macro para conectarme a la BD desde el Word y POR SUPUESTO que la cadena de conexi贸n no fue la misma. Aqui le envio las dos cadenas para que las examine y, POR FAVOR, me sugiera que hacer para estos dos casos de Office que en un inicio pens茅 que el de 97 servir铆a para todos, o a lo mejor existe una forma com煤n, e independientemente del Office, para hacer esto.
Cadena de Conexi贸n Office 97:
.OpenDataSource Name:= _
App.Path & "AplicarInstrumento.mdb", ConfirmConversions:=False, ReadOnly:=False, LinkToSource:=True, AddToRecentFiles:=False, _
PasswordDocument:="", PasswordTemplate:="", WritePasswordDocument:="", WritePasswordTemplate:= _
"", Revert:=False, Format:=wdOpenFormatAuto, Connection:="TABLE Tmp_AplicacionInstrumento_I", _
SQLStatement:="SELECT * FROM [Tmp_AplicacionInstrumento_I]", SQLStatement1:=""
Cadena de Conexi贸n Office 2k3:
.OpenDataSource Name:= _
App.Path & "AplicarInstrumento.mdb", ConfirmConversions:=False, ReadOnly:=False, LinkToSource:=True, AddToRecentFiles:=False, _
PasswordDocument:="", PasswordTemplate:="", WritePasswordDocument:="", WritePasswordTemplate:="", Revert:=False, _
Format:=wdOpenFormatAuto, Connection:= "Provider=Microsoft.Jet.OLEDB.4.0;Password="""";User ID=Admin;Data Source=" & App.Path & "AplicarInstrumento.mdb;Mode=Read;Extended Properties="""";Jet OLEDB:System database="""";Jet OLEDB:Registry Path="""";Jet OLEDB:Database Password="""";Jet OLED", SQLStatement:="SELECT * FROM `Tmp_AplicacionInstrumento_I` ", SQLStatement1:="",
SubType:=wdMergeSubTypeAccess
Bueno, disculpe tanta labia, est谩 de m谩s decirle que son cosas que necesito pero que usted no est谩 en la obligaci贸n de responder, de hecho son preguntas extensas quiz谩s f谩ciles o complicadas, pero bueno siempre que disponga del tiempo y el deseo pues bienvenido sea.
Saludos, y agradecido, Orlando
De antemano le estoy muy agradecido y en lo que le pueda ayudar, que est茅 a mi alcance, pues sin duda lo har茅.
Preguntas (IMPORTANTE --> Trabajo con Visual Basic 5.0 y Crystal Report 4.5)
===========================================================
1) Resulta que tengo un reporte que por cuestiones de ahorro de papel me he visto en la obligaci贸n de mostrar sus datos con Fuente: Arial Narrow = 8, de esta manera, en la pantalla la informaci贸n es impsoible de leer pero cuando se manda a imprimir, todo sale muy bien, o sea, con tama帽o 8 y muy legible.
Entonces mi pregunta est谩 en que si es posible mostrar en pantalla el reporte a un porciento mayor (150%, 200%) tal y como se hace con Word para resolver el problema de poder leer sus datos y luego cuando se imprima pues lo haga en el porciento que trae por defecto en tiempo de dise帽o.
2) Necesito mostrar un reporte en formato .RTF (o Word) utilizando las propiedades correspondientes al ActiveX del Crystal Report: .PrintFileName = "Nombre del fichero", .PrintFileType = crptRTF, .Destination = crptToFile; resulta que todo est谩 bien hasta que trato de hahacerle el .PrintReport que me da un error de automatizaci贸n de esos que uno no sabe ni por qu茅 suceden. Lo curioso es que a pesar de este error el proceso de export谩rmelo funciona, lo 煤nico que ah铆 mismo me da el error.
Si comienzo a trasear el c贸digo, cuando llego a la instrucci贸n:
Res% = F_Main.CrystalReport1.PrintReport, me genera dicho error, que adem谩s no se puede interceptar si continuo con la pr贸xima l铆nea y vuelvo a intentar listarlo pues en la variable Res% me devuelve el numero:
20520 -->> El trabajo de impresi贸n ya ha empezado. Est谩 intentando iniciar un trabajo de impresi贸n que ya est谩 iniciado. Esto puede suceder cuando el usuario inicia un trabajo de impresi贸n y lo quiere volver a imprimir antes de que haya terminado el anterior.
Ahora bien cuando hago la misma operaci贸n con cualquier otro reporte, me funciona sin problemas. Cabe se帽alar que este que trato de exportar tiene un dise帽o un poco complicado, es una Factura, con Logo de la empresa incluido, etc, etc
Adem谩s el reporte que intento exportar a Word cuando lo muestro .Destination = crptToWindow o crptToPrinter todo funciona muy bien.
3) Estoy haciendo una alpicaci贸n en la cual necesito imprimir en un docuento Word los datos provenientes de una BD Access 97, todo m谩s que sencillo, todo me funciona bien, a este docuento Word le cree una Correspondencia con la Base de Datos y todo est谩 perfecto, inserto en el mismo los campos de los cuales deseo mostrar sus datos y todo funciona bien. Pero resulta que este documento lo llamo desde el Visual Basic y el origen de los datos es una tabla que genero en tiempo de corrida y a partir de varias consultas, o sea, que he tenido que correr una Macro de conexi贸n a la base de datos para cojer el c贸digo que genera la misma e insertarlo en el c贸digo del programa mio, m谩s cuando el camino de este programita as铆 como de la fuente de datos no es fijo, es a elecci贸n del cliente, por supuesto que esta macro la elimin茅 del documento pues no me sirve para nada. Pero de todas maneras el problema no est谩 en nada de lo que escrito, todo esto ha sido una intoducci贸n, adem谩s cosa que usted conoce, el PROBLEMA GRAVE EST脕 en que esta base en Access tiene PASSWORD y cuando esto sucede ya la cosa cambia, o sea, cuando tratas de crear la Macro y est谩s en el proceso de abrir el origen de datos en la creaci贸n de la correspondencia, esta te pide el password de la BD todo muy bien, pero cuando miras el c贸digo generado por dicha Macro, ese password no aparece por ning煤n lado y por ende cuando intentas abrir desde tu aplicaci贸n el documento Word, para este mostrar los datos insertados en el documento pues te pide EL PRECIADO PASSWORD. Est谩 de m谩s decirle lo que tuve que hacer, cosa que no me ha gustado ni un poquitico pues es un invento macabro, me he visto en la obligaci贸n de crear una base vac铆a, SIN PASSWORD, y que tenga vinculada la tabla de aquella, CON PASSWROD, para que entonces se pueda conectar el .DOC a esta BD sin problemas y mostrar los datos correspondientes.
Por favor c贸mo resolver este PROBLEMA de pasar la conexi贸n del .DOC a la BD y que esta tenga alg煤n Password ????
Cadena de Conexi贸n:
=================
.OpenDataSource Name:= _
App.Path & "AplicarInstrumento.mdb", ConfirmConversions:=False, ReadOnly:=False, LinkToSource:=True, AddToRecentFiles:=False, _
PasswordDocument:="", PasswordTemplate:="", WritePasswordDocument:="", WritePasswordTemplate:= _
"", Revert:=False, Format:=wdOpenFormatAuto, Connection:="TABLE Tmp_AplicacionInstrumento_I", _
SQLStatement:="SELECT * FROM [Tmp_AplicacionInstrumento_I]", SQLStatement1:=""
4) Algo que tiene que ver con esto de la cadena de conexi贸n de un .DOC a una BD y es que esta Aplicaci贸n la tengo instalada en una empresa donde hay varias PC y, as铆 mismo, diferentes sistemas operativos, o sea, 98 con Office 97 y XP con Office 2k3, yo donde estoy desarrollando la aplicaci贸n tengo la primera de las variantes, as铆 es que en las m谩quinas donde est谩 configurado igual, en la empresa, no me da ning煤n tipo de problema; peroooooooo, cuando es Office 2003 ya la cosa explota, porque la cadena de conexi贸n es otra, o sea, de esto me di cuenta porqie llev茅 los fuentes para aquella empresa y corr铆 por trazas el programa, hice una Macro para conectarme a la BD desde el Word y POR SUPUESTO que la cadena de conexi贸n no fue la misma. Aqui le envio las dos cadenas para que las examine y, POR FAVOR, me sugiera que hacer para estos dos casos de Office que en un inicio pens茅 que el de 97 servir铆a para todos, o a lo mejor existe una forma com煤n, e independientemente del Office, para hacer esto.
Cadena de Conexi贸n Office 97:
.OpenDataSource Name:= _
App.Path & "AplicarInstrumento.mdb", ConfirmConversions:=False, ReadOnly:=False, LinkToSource:=True, AddToRecentFiles:=False, _
PasswordDocument:="", PasswordTemplate:="", WritePasswordDocument:="", WritePasswordTemplate:= _
"", Revert:=False, Format:=wdOpenFormatAuto, Connection:="TABLE Tmp_AplicacionInstrumento_I", _
SQLStatement:="SELECT * FROM [Tmp_AplicacionInstrumento_I]", SQLStatement1:=""
Cadena de Conexi贸n Office 2k3:
.OpenDataSource Name:= _
App.Path & "AplicarInstrumento.mdb", ConfirmConversions:=False, ReadOnly:=False, LinkToSource:=True, AddToRecentFiles:=False, _
PasswordDocument:="", PasswordTemplate:="", WritePasswordDocument:="", WritePasswordTemplate:="", Revert:=False, _
Format:=wdOpenFormatAuto, Connection:= "Provider=Microsoft.Jet.OLEDB.4.0;Password="""";User ID=Admin;Data Source=" & App.Path & "AplicarInstrumento.mdb;Mode=Read;Extended Properties="""";Jet OLEDB:System database="""";Jet OLEDB:Registry Path="""";Jet OLEDB:Database Password="""";Jet OLED", SQLStatement:="SELECT * FROM `Tmp_AplicacionInstrumento_I` ", SQLStatement1:="",
SubType:=wdMergeSubTypeAccess
Bueno, disculpe tanta labia, est谩 de m谩s decirle que son cosas que necesito pero que usted no est谩 en la obligaci贸n de responder, de hecho son preguntas extensas quiz谩s f谩ciles o complicadas, pero bueno siempre que disponga del tiempo y el deseo pues bienvenido sea.
Saludos, y agradecido, Orlando
