SoloCodigo

Hola, pues sustituye la SQL por:

Set rs = base.OpenRecordset("select * from personal where fecha between #" & Text1.Text & "# and #" & Text2.Text & "#")

Saludos y suerte

Hola, yosita:

Tú dices textualmente
La mala noticia es que solo funciona bien con el ejemplo que tu me mandaste, es decir, en el campo descripcion, copie un campo de mi BD original y el error volvio.

Mi rutina no copia un campo de una BD en otro campo... sino un fichero (DE EXTENSIÓN .RTF, NO .DOC) en un campo memo de tu BD.

Yo genero un documento en Word, lo grabo con formato .rtf y lo grabo en el campo tipo memo.  Es superpráctico, y luego ya ves que se usa perfectamente.

Ojalá le saques el jugo y des con el motivo de tu fallo.  Un beso.

Pues es que no le das la orden de IMPRIMIR; sólo le has dicho lo que tiene que imprimir...
Mientras no le envíes la orden de
Printer.EndDoc
la impresora no hace nada más que acumular datos en el buffer...

Tu código tendrá que ser:

case is=”imprimir”
printer.print tab(5);text1.text
Printer.EndDoc

y verás cómo te lanza el texto puntualmente.

Saludos y suerte

Yo empleo las búsquedas habitualmente así:

Buscar = "rut like '" & NumRut & "'"
Data2.Recordset.FindFirst (Buscar)
If Data2.Recordset.NoMatch Then
MsgBox("No se encuentra el dato que se buscaba")
Exit Sub
End If

A ver si a la tercera va la vencida, a pesar de que veo bien los anteriores métodos...  Saludos

Perfectamente, puedes usar dos bases de datos en tu aplicación, y también usar una base de datos desde dos aplicaciones de forma simultánea.
Lo único que no puedes hacer (creo yo por mi experiencia) es tratar ambas BD en una misma SQL. Pero en tu caso yo creo que eso no va a crearte problema, porque me da la impresión de que la tabla "clientes" sólo vas a actualizarla desde la primera aplicación, y en esta segunda vas solamente a leer sus datos, con un FisrtFind, por ejemplo.
Para tu tranquilidad puedo garantizarte que nosotros usamos simultáneamente bases de Oracle y de Access, intercambiando datos entre ellas.

Saludos y suerte

Pues no me queda más que pedir perdón por la metedura de pata.
Efectivamente en el disco 3 de Visual Studio viene incluida la instalación de CR, la misma versión que soportaba VB5.0
Como hoy tengo problemas en mi PC no puedo instalarla para indicarte de qué versión de CR se trata.

¿Te imaginas lo que sería incluir en cada ejecutable todas las librerías que utiliza?. Como si quisieras incluir además todas las API's y módulos del sistema, para poder ejecutarlo sin depender de Windows... En primer lugar los ejecutables serían enormes: para hacer una simple calculadora necesitarías un ejecutable de un montón de Mb... y con la desventaja de que todos los .exe serían una repetición de lo mismo...

Cuando preparas una instalación ya se incluyen automáticamente todas las librerías que usa ese ejecutable, pero al instalarlo sólo se copian las que el equipo necesite; así se evitan repeticiones... Eso es lo lógico; lo que tú  pides, a mí me parece que va contra la lógica.

Perdóname si mi opinión es consecuencia de no entender tu punto de vista, y recibe un cariñoso saludo.

Os ruego ayuda urgente:

Yo tengo dos discos, uno con Xp y otro con 98; éste lo uso casi exclusivamente para programar y preparar las instalaciones del VB.

Cuando pasé a hacerlo con Xp casi me muero del susto: todos mis programas dejaban de funcionar en cuanto actualizaba algún cambio...

Los que tengáis práctica en esto, ¿qué tengo que hacer para que pueda trabajar en Xp con garantía de que mis ejecutables no me den problemas al rodarlos en 98?

Hoy me ha cascado el disco de Windows'98; por eso lanzo este SOS URGENTE.  Muchas gracias a todos

Agradecido de antemano. Y no te preocupe la demora.

Hola de nuevo, Wolfstein:

Tú puedes utilizar una base de datos de Access, sin que ello te obligue a tener instalado Access en el equipo en el que vayas a ejecutar la aplicación en VB que vaya a manejar esa base de datos. Lo único que no podrás hacer es manejar los ficheros.mdb directamente desde fuera de la aplicación; las librerías necesarias para que VB pueda manejar esos ficheros se incorporarán en el equipo-destino al instalar tu paquete.

Del mismo modo podrás manejar ficheros.doc, con formato de Word. Lo que, naturalmente, no podrás será abrir estos ficheros con Word si no tienes instalada esa parte de Office.

Hasta otra.

Yo creo que tú necesitas el API-Guide, con el que no sólo resolverás este problema sino 2.500 más...

Aquí lo encontrarás
http://www.csi-net.net/~jhunsberger/ware/Freeware.htm

Saludos y suerte

Yo no veo el inconveniente en que inmediatamente antes del unload o hide del formulario que quieres mantener visible, añadas esta línea de código
Sleep = SleepEx(5000, 0) ' Si quieres hacer una pausa de 5 segundos

O que pongas esa línea dentro de ese formulario, allá donde desees mantener unos segundos más la imagen en pantalla...

Pero, claro, eso ya tienes que hacerlo tú.

Saludos de nuevo y que des con la solución

Por ejemplo puedes usar este truquito:

With frmPropietarios.datEstablecimientos.Recordset
txtNit = .Fields("Nit") & " "
txtRazonSocial = .Fields("Razon_Social") & " "
txtDireccion = .Fields("Direccion") & " "
If .Fields("Grupo_Codigo") = Null Then
txtGrupo = " " ' NO PONGAS "", SINO " "
Else
txtGrupo = .Fields("Grupo_Codigo")
End If
cmbUso.Text = .Fields("Uso") & " "
txtActividad = .Fields("Actividad") & " "
If .Fields("Observaciones") = mNulo Then
txtObservaciones = " " ? IDEM
Else
txtObservaciones = .Fields("Observaciones")
End If
txtSolicitud = .Fields("Nro_Solicitud") + 0 '(En los campos numéricos... Este sería de texto, así que:  & " ")

etc. etc.

En los campos de fecha puedes sustituir por Date si es nulo...

Saludos y que te sirva de solución