Post, Crea o modifica?

[krilea]

Hola!
Tengo una dudilla que no se como resolverla. Estoy trabajando en delphi 7 con Access.
Cuando quiero ingresar un registro nuevo hago ADOQuery1.insert y cuando quiero modicarlo ADOQuery1.edit. Una vez termino para guardar los canvio hago ADOQuery.post.

El problema está en que cuando hago el post necesitaria saber si he heco el post de un insert o el post de un edit porque tengo que hacer comprovaciones distintas en cada uno de los casos.

Alguien sabe como puedo saberlo?

Muchas Gracias!!

[santi33a]

simplemente preguntas

if ADOQuery1.state = dsInsert then begin
// estoy insertando
end
else if ADOQuery1.state = dsEdit then begin
// estoy editando
end;


Normalmente esto se usa en el evento BeforePost del ADOQuery

Santiago

[destrukthor]

Siguiendo el hilo me dice el error.

[Error] Compras.pas(417): Undeclared identifier: 'dsInsert'

y el codigo es simple.


IF (Key=#13) THEN BEGIN
IF DBGrid1.Fields[0].Value<>Null THEN Begin
IF MD.tbMovCom.State = dsInsert THEN
MD.tbMovCom.Post;
End;
END;


Es aqui donde se coloca y muestra el error.
¿Porque?
me faltara a algun unit??
Uso tablas paradox 7 y delphi 7.

[Sick boy]

Cambia el igual por un IN

if ADOQuery1.state in [dsInsert] then
begin
// estoy insertando
end
else if ADOQuery1.state in [dsEdit] then
begin
// estoy editando
end;

[destrukthor]

Sorry amigo, pero me sigue dando el mismo error.

[Error] Compras.pas(419): Undeclared identifier: 'dsInsert'


IF (Key=#13) THEN BEGIN
IF DBGrid1.Fields[0].Value<>Null THEN Begin
IF MD.tbMovCom.State IN dsInsert THEN
ShowMessage('Pasa a Modificar')
// MD.tbMovCom.Post;
End;
END;


Gracias ¿me puedes ayudar?

[roman]

me faltara a algun unit??

Agrega la unidad DB.

// Saludos

[Sick boy]

Lee mi ejemplo.

El dsInsert debe estar entre corchetes [dsInsert]

Tambien puedes revisar la ayuda de State, es muy sencillo, solo hay que pulsar F1.

Saludos

[destrukthor]

Resuelto el problema, me faltaba el [] y el unit DB.

Muchas gracias nuevamente.:D

[roman]

¿Para qué quieren el IN y los []? Bastaba incluir la unidad DB y la comparación que se tenía originalmente:


IF MD.tbMovCom.State = dsInsert THEN


// Saludos

[destrukthor]

ya lo verifique y el codigo inicial estaba bien tb solo faltaba el unit DB.
Gracias...:D

[Sick boy]

¿Para qué quieren el IN y los []? Bastaba incluir la unidad DB y la comparación que se tenía originalmente:


Tienes razón.

Yo uso el IN, porque el tipo TDataSetState puede tener diferentes valores, y a veces me interesa que se realice una acción si se cumplen alguno de los valores. Usando el IN no tengo que hacer un OR.

Y si usas IN, el tipo a de ir entre corchetes, creo yo....

En este caso concreto no hacia falta el IN, y lo de la unit db no se me había ocurrido, ya que en mi caso, esa unit se añade automaticamente.

[roman]

Así es, State puede tener varios valores y cuando interesa saber si es uno de entre varios entonces IN es lo mejor. De hecho, cuando más lo he usado es justo para lo contrario: saber si el DataSet está en edición o inserción sin importar cuál exactamente:


if DataSet.State in [dsInsert, dsEdit] then


y coincido contigo pues es mucho más cómodo que usando OR.

Por cierto, en esa misma unidad DB se define la constante


const
dsEditModes = [dsEdit, dsInsert, dsSetKey];


de manera que de hecho se puede poner


if DataSet.State in dsEditModes then


para saber si el DataSet se está editando.

// Saludos

[Sick boy]

Yo lo uso exactamente para los mismo, para saber cuando esta en modo edición.

Y no conocia dsEditModes, asi que otra cosa más que he aprendido hoy.

[destrukthor]

Gracias yo tambien he aprendido algomas y vastante mas.

Una pequeña consulta y para que me aconsejen, yo uso tablas paradox, y aqui he escuchado mucho hablar de SQL o MySql, lo que estoy usando (paradox), me servira para una red o es preferible aprender de inmediato MySql.
Recuerden q soy novato en Delphi.

Gracias por las Ayudas recibidas..:rolleyes:

[Sick boy]

La pregunta es tan amplia.......

Paradox en red funciona mal. Se que algunos diran que se puede hacer, pero en mi opinión funciona mal. Paradox no se diseñó para usarlo en red.

En cualquier caso, si utilizas paradox en red, tendrás que utilizar SQL, ya que con objetos TTable es una locura.

SQL es un estandar de lenguaje para acceder a bases de datos.
No es una base de datos en si misma, sino un conjunto de reglas comunes a todas (o casi todas) las bases de datos.

Asi que no tienes que aprender MySQL, sino SQL.

Luego tendrás que decidir que motor de base de datos es mejor para la aplicación que estes desarrollando.

Yo prefiero FireBird antes que MySql, pero es para gustos.

Y para terminar, cada motor de base de datos suele tener sus extensiones a la norma general de SQL, de modo que las sentencias SQL "basicas" son las mismas, pero cada GDB te permitirá ciertas funciones "extendidas".

Mi recomendación, por experiencia propia, cuanto antes migres TODO a SQL mejor, aunque el proyecto sea pequeño, nunca se sabe....

[destrukthor]

Mil gracias por el consejo, terminare este pequeño proyecto de pruebas q estoy haciendo y me pondre en marcha a aprender SQL.
Gracias.. Amigo;)

[roman]

Hola, en mi opinión la gran limitante de paradox es la cantidad de usuarios y/o información que puede manejar. No obstante, prácticamente no he tenido problema alguno al usarlo en red. Pero además, sea o no en red, definitivamente paradox está hecho para ser usado con componentes Table. El SQL que maneja no es más que una emulación que trabaja muy lento. SQL es la mejor opción cuando se usa con motores que realmente son cliente-servidor. Con paradox la cosa es alrevés. Las componentes Table están diseñadas para trabajar con los índices que se establecen mientras que TQuery no usa esos índices y cualquier consulta SQL que no use índices es, la más de las veces, muy lenta.

Eso sí, el hecho de no ser cliente-servidor y de haber actualmente varias opciones libres que sí lo son (como las que menciona Sick boy), hace difícil entender que se siga optando por paradox, o access que para el caso es lo mismo.

Por otra parte, destrukthor, te recomiendo que esto último que preguntas lo hagas en otro hilo o busques en los foros porque nos estamos saliendo del tema original.

// Saludos

[Sick boy]

Yo ya sabia que hay gente trabajando con paradox en red y que les funciona bien!!!

pero
Con paradox la cosa es alrevés. Las componentes Table están diseñadas para trabajar con los índices que se establecen mientras que TQuery no usa esos índices y cualquier consulta SQL que no use índices es, la más de las veces, muy lenta.


Esto si que no lo sabia, y puede ser el motivo por el que nunca consegui que funcionara como yo queria o esperaba, ya que el 90% de la aplicación usaba querys.

No coincido con lo de los indices y los querys, pero puedo estar equivocado.

Con lo que coincido es que ya no tiene mucho sentido usar paradox, y pasarte el dia reconstruyendo indices, reparando autoincrementales y liberando los lck.

Y es cierto que hay que abrir otro hilo, porque esto ya es otro tema.

[roman]

ya no tiene mucho sentido usar paradox, y pasarte el dia reconstruyendo indices, reparando autoincrementales y liberando los lck.


El punto es: normalmente yo no tengo que hacer esta tareas. Nunca. Las únicas veces en que he debido regenerar índices es cuando falla la energía eléctrica y la pc se apaga a la brava. Por ello es que para mi esa no es la razón para no usar paradox.

No obstante, como estamos de acuerdo en ya no usar paradox, pues mal haríamos discutiendo de algo que ninguno va a usar :D

// Saludos

[Sick boy]

Nunca. Las únicas veces en que he debido regenerar índices es cuando falla la energía eléctrica y la pc se apaga a la brava
Nunca???
O cuando el windows se cuelga....
O cuando intenta enredar en la base de datos desde access...

Cuando el sistema esta vendido a muchos clientes, estos casos "raros" suceden casi a diario.
De hecho, hice una aplicación que detectaba estos cierres "bruscos" y reparaba de forma automatica, lo cual me quitaba muchos dolores de cabeza.

Pero, y cuando de vez en cuando desparecen datos??

Podriamos abrir otro hilo y poner a parir a Paradox, dBase y compañia, y compararlas con las bases de datos libres actuales (FB, MySQL, DB2, ...), que también tienen sus cositas.

Por mi parte, creo que este hilo ha sobrepasado el proposito inicial, no te parece??

[roman]

Sí, si me parece. Y como dije, a fin de cuentas estoy de acuerdo contigo. No tiene caso elaborar sobre algo ya muerto: paradox, access, dbase, etc. (bueno, dbase aún me sirve a veces como medio de transferencia entre un motor y otro)

// Saludos