|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - J.M.Movilla
Páginas: 1 [2] 3 4 ... 17
26
« en: Jueves 11 de Septiembre de 2003, 00:58 »
Ahí estaremos con nuestros granitos de arena. A ver si conseguimos crear una referencia de Visual de consulta obligatoria...
Ya veo a algunos de tus amigos/as haciendo la ronda persistente... sacándole jugo al tema...
27
« en: Viernes 29 de Agosto de 2003, 16:57 »
es que no te das cuenta de que el Número de Factura no puede ser el Bookmarck de una tabla... el Bookmarck ha de ser obligatoriamente el NÚMERO DEL REGISTRO, el puntero, mejor dicho...
28
« en: Viernes 29 de Agosto de 2003, 00:44 »
Para hacer lo que tú quieres has de utilizar el Crystal Report. Los informes hechos con DataReport son fijos...
Y por supuesto, el cliente tendría que tener instalado el Crystal o su runtime.
Saludos
29
« en: Jueves 28 de Agosto de 2003, 23:51 »
En tu consulta inicial decías: si yo estoy en la factura nº 12 y pulso un boton para mostrar un formulario donde hay la lista de articulos, al cerrar ese form de articulos, el recordset se mueve al primero
Está claro que hablas del registro, no de un textbox... Mis respuestas van todas dirigidas a recuperar el registro inicial, la factura a la que apuntaba antes de presentar el segundo formulario. No sé qué quieres hacer con el textbox al que te refieres últimamente...
Saludos
30
« en: Jueves 28 de Agosto de 2003, 11:49 »
nReg está definido como Integer... es decir, es el número de registro del recordset... porque tú hablabas de que al recuperar el formulario SE TE IBA EL PUNTERO AL PRIMER REGISTRO... Por eso te doy la fórmula para que recupere el registro al que apuntaba antes de leer el segundo formulario...
Si lo que quieres es mantener el contenido del textbox tendrías que definir una variable de tipo texto, asignarla y luego recuperarla:
Dim cText As String
cText = Text1.Text
frmForm2.Show vbModal
Text1.Text = cText
Ahora sí recuperarías el contenido original del textbox...
Saludos
31
« en: Jueves 28 de Agosto de 2003, 10:50 »
Vamos a ver. Detrás de tu línea:
nReg = Adodc1.Recordset.BookMark
pondrás la línea de presentar el segundo formulario:
frmForm2.Show vbModal
y finalmente, para que cuando hagas el UnLoad del segundo formulario, al volver al primer formulario recupere el puntero del recordset:
Adodc1.Recordset.BookMark=nReg
Espero que ahora sí te funcione.
32
« en: Miércoles 27 de Agosto de 2003, 23:34 »
Siento no ser capaz de deciros quién me enseñó esos trucos... Pero lo que sí puedo afirmaros es que no lo he inventado yo... O sea que os agradezco vuestros elogios, pero no soy yo quien debe recibirlos...
Gracias.
33
« en: Miércoles 27 de Agosto de 2003, 21:08 »
Ya irás dándote cuenta, Jordi, de que en realidad en programación hay muy pocas cosas extrañas... la inmensa mayoría de las veces esas cosas son totalmente lógicas...
En este tu caso, cuando abres el nuevo formulario modificarás el puntero del recordset que estás presentando, o cuando menos al volver al formulario padre se habrá perdido el puntero del grid que tienes en pantalla...
Si tú, antes de leer el segundo formulario defines una variable con el puntero del registro, por ejemplo
nReg = Adodc1.RecordSet.Bookmark
y cuando vuelvas del formulario secundario apuntes a ese registro mediante
Adodc1.RecorSet.Bookmark = nReg
es de esperar que te encuentres que el grid está apuntando a la misma factura que antes de cambiar de formulario.
Saludos y suerte
34
« en: Miércoles 27 de Agosto de 2003, 20:52 »
Posiblemente por la forma como te lo he dicho has podido interpretar que lo hacía con enfado... Al contrario: lo que ocurre es que me alegra el que al fin hayas caído en la cuenta de que existen las SQL para manejo de los registros... y seguro que ahora te meterás en el tema y aprenderás sus mandatos, sus cláusulas, sus sentencias... y verás que merece la pena perder(?) / GANAR(!) el tiempo introduciéndote en las entrañas de las SQLs...
Un abrazo
35
« en: Miércoles 27 de Agosto de 2003, 17:12 »
Cuando borras el registro del recordset tienes que tener en cuenta que al volver al DataGrid sepa que esa línea ha desaparecido. Si no cuidas ese detalle te da error por perderse entre varias filas entre las que no encuentra donde apuntar...
With Adodc1.Recordset
.Delete
.Update
If Not .BOF Then
.MovePrevious
DataGrid1.SetFocus
End If
End With
Con estas líneas, además de borrar el registro cambias el puntero y evitarás el error, espero...
Saludos y suerte
36
« en: Miércoles 27 de Agosto de 2003, 16:30 »
Porque fíjate qué diferencia puede haber entre el código que has aceptado finalmente y el que yo te proponía, que era exactamente (si no me lo han cambiado las brujas...):
Me.Adodc1.RecordSource = "Select SUM(Importe) As Total from Gastos " & _
"Where Fecha >= DateValue(""" & DTPick1 & """)" _
& " And Fecha <= DateValue(""" & DTPick2 & """)"
Me.Adodc1.Refresh
Pues simplemente que en mi ejemplo la condición era entre fechas y en tu caso filtras por el número de factura... y que los objetos lógicamente tienen diferentes nombres... Pero veo que has llegado a aceptar el uso de una SQL para confeccionar el RecordSet, como Dios manda...
Saludos y suerte
37
« en: Martes 26 de Agosto de 2003, 22:30 »
Hacía tiempo que no se sentía tu presencia... Y curiosamente ahora lo haces "aprovechando la oportunidad"... No creo que nadie aprecie oportunidad ninguna, sino simplemente que... "al no tener oportunidad" de intervenir en ningún mensaje, meto mi cuña publicitaria, como he venido haciendo en mis últimas 8-10 intervenciones...
Deseo que te vaya bien en tu foro, pero te aconsejo, como lo hace Pablo Tilotta, que cuides tus incursiones en "Solocodigo", respetando los límites establecidos en un foro de consulta, donde los negocios deben quedar marginados.
Gracias, saludos y suerte.
38
« en: Martes 26 de Agosto de 2003, 18:20 »
Mira a ver si esto que te mando se ajusta a lo que tú buscas...
Saludos
39
« en: Lunes 25 de Agosto de 2003, 16:19 »
Ya sabes que cada maestrillo tiene su librillo, pero teóricamente deberías llevar el orden que habitualmente se viene empleando:
1.- Presupuesto (no obligatorio). Cuando éste se acepta pasan sus datos a
2.- Albarán (siempre debe haber un albarán que controle las salidas de artículos y/o trabajos realizados), y
3.- Factura (para gestionar la contabilidad de los albaranes)
Si a la Tabla1 le añades un campo de NúmPresup y otro de FechaPresup ya tienes la posibilidad de incorporar los presupuestos en la misma tabla general, pudiendo dejar esos dos campos en blanco cuando no hubo presupuesto previo. Igualmente puedes hacer facturas directas, sin previo albarán (no recomendable) simplemente dejando vacíos los campos NúmAlbarán y FechaAlbarán...
Pero, repito, tú has diseñado tu aplicación de otro modo, pues tú tienes el 100 de razón, y los de fuera (como en el mus...) a callar y dar tabaco...
Que te salga bonito.
40
« en: Lunes 25 de Agosto de 2003, 13:15 »
Si yo fuera catedrático, ten por seguro, amigo Brroz, que te daría un 10 por lo bien que te has explicado para que Jordi_BCN entienda la SQL con la que pasarán los registros de la Tabla1 a la Tabla2. Pero me da la impresión de que Jordi lo que tiene es una Tabla1 de Albaranes servidos y no facturados, y una Tabla2 de los mismos datos cuando ya hayan sido facturados...
Vamos a ver, Jordi... ¿Y no te resultaría más simple añadir a esa Tabla1 un campo de FechaFactura, e incluso otro campo de FechaAbono?
Si tú tienes FechaFactura con valor = Null, ES UN ALBARÁN (no facturado)... El día que lo facturas actualizas FechaFactura y YA ES FACTURA (como si lo hubieras pasado a Tabla2, pero con sólo ponerle la fecha al campo FechaFactura)... Igual harías con la FechaAbono, para luego hacer las consultas con WHERE FechaFactura = Null para extraer los Albaranes, con WHERE FechaFactura <> Null And FechaAbono = Null para obtener las Facturas pendientes de abonar y WHERE FechaFactura <> Null And FechaAbono <> Null para saber lo Factura y ya Cobrado...
Creo que te lías mucho con lo de dos tablas para un mismo concepto...
Saludos y suerte
41
« en: Lunes 25 de Agosto de 2003, 12:43 »
Veo que estás muy empeñado en conseguir una grilla con filas vacías... Creo que eso no va a ser posible si utilizas el DataGrid (porque maneja REGISTROS de una tabla... y no puedes hacer filas si no hay registros... salvo una para el AddNew...)
Pero el FlexGrid maneja variables independientes, que tú puedes luego incorporar a una base de datos... Mira a ver si te sirve este código que te adjunto... Con él puedes no sólo presentar un número determinado de filas vacías, sino incluso añadir nuevas filas vacías en ejecución.
Saludos y QUE TE SIRVA!!!
42
« en: Lunes 25 de Agosto de 2003, 11:51 »
Pues, efectivamente con la declaración de las variables justo cuando vayas a usarlas te evitas asignar memoria innecesariamente.
Si vas a asignar tipos Long o sobre todo Variant puede que merezca la pena el ahorro, lo mismo que si la rutina gestiona un bucle persistente; pero en una subrutina que dura milésimas de segundo por lo general no suele importar que ocupe unos bytes del RAM, sabiendo que al terminar la subrutina esa memoria va a quedar liberada. Más importante es el hecho de que cada vez que hacemos asignaciones nos exponemos a que la memoria se recupere fragmentada... lo cual va a enlentecer el flujo de la aplicación... y eso sí es motivo para que evitemos asignaciones innecesarias.
Saludos
43
« en: Sábado 23 de Agosto de 2003, 23:27 »
Vamos a ver, Jordi:
El ejemplo que te envió Angel ya lo tiene previsto; concretamente la línea que dice If Adodc1.Recordset!Numamigo = Val(txt_codigo) Then significa que si ya existe un registro en el que el Número de amigo sea igual al Número que tu acabas de introducir... Y le manda que te presente la ficha del amigo que ya tiene asignado ese número...
O sea que, tranquilo, que no vas a tener números repetidos.
Saludos
44
« en: Viernes 22 de Agosto de 2003, 19:02 »
A ver si te gusta este código...
Saludos
45
« en: Jueves 21 de Agosto de 2003, 20:36 »
A ver, Giomar: Hace meses surgió este mismo tema y quedó resuelto...
Cuestiona si existe el carácter ' en el campo que va a formar parte de la consulta, por ejemplo:
n = InStr( Campo, "'") ' Comilla simple entre dos comillas dobles
if n > "0" Then
Campo = Left( Campo, n) & "'" & Mid( Campo, n+1)
end if
Con ello hemos sustituído una comilla simple por dos comillas simples seguidas... que surte el mismo efecto que cuando se usan dos comillas dobles seguidas para insertar comillas en una variable entrecomillada... Jo... qué difícil es de explicar una cosa tan "simple"...
Verás cómo te funciona... Lo cual me producirá una gran satisfacción... Un saludo.
46
« en: Jueves 21 de Agosto de 2003, 02:54 »
Creo que las vacaciones os tienen un poco desconectados... No habéis advertido mi mensaje en Visual Basic advirtiéndoos de la conveniencia de que borréis el mensaje titulado Busco Chicas Entre Edades De 13 ha 20 . Es francamente indignante y está creando crispación en el foro.
Por favor, tomad las medidas adecuadas de forma urgente. Gracias
47
« en: Miércoles 20 de Agosto de 2003, 01:22 »
Aquí tienes el código adecuado para que hagas una consulta sobre dos bases de datos diferentes, abriéndolas con ADO (aunque no precisamente con DataEnvironment, pero eso ya sabrás resolverlo tú...)
Saludos y que termines encontrando todas las soluciones
48
« en: Martes 19 de Agosto de 2003, 20:07 »
Os ruego paséis la aspiradora con la mayor urgencia posible y limpiéis la basura de Busco Chicas... porque me dan tantas ganas de vomitar como le dieron a su madre cuando le echó fuera... A ver si le da por ir a la escuela y aprende al menos a escribir, aunque no tenga capacidad para más...
49
« en: Martes 19 de Agosto de 2003, 10:55 »
Mira... Ejecuta Visual, abre "Asistente para aplicaciones de VB" y verás cómo el asistente te da la solución al 100%. Luego ya podrás seguir esos pasos para aplicarlo a tu proyecto.
Saludos y suerte
50
« en: Martes 19 de Agosto de 2003, 10:50 »
Claro, el problema es que no has hecho un análisis previo por el que definas qué campos han de ir a una tabla y cuáles a otra tabla: porque necesitan controles diferentes las facturas, los artículos, los clientes... y al incrementarse los registros de cada tabla tienes que evitar la repetición de sus ID... Pero todo esto es elemental, para que lo hagas ANTES de ponerta a programar la confección de la factura.
Bueno, veo que has hecho una pregunta paralela con el título Necesito ideas para realizar una factura y que MiguelPG te da una adecuada respuesta. Así que saludos y que lo resuelvas pronto.
Páginas: 1 [2] 3 4 ... 17
|
|
|
Mostrar Mensajes
