Trabajar sin DataSets

On Wed, 4 Apr 2007 06:57:25 +0200, "Juan Diego Bueno"
wrote:

Es más, si ves aplicaciones de ejemplo de
Microsoft, muchas de ellas trabajan con datasets tipados.

Esas aplicaciones son juguetes que apenas hacen nada, y tienen muchos
miles de líneas de código.

Yo no se si el problema de velocidad vendrá porque ADO.NET en general sea un
modelo lento, o simplemente por la propia naturaleza de .NET, ya que no
sirve para compilar a código nativo, sino intermedi

.NET es rápido de sobra, pero está claro que los que diseñaron ADO.NET
nunca han creado software de gestión.


Saludos

"Alfredo Novoa" escribió en el mensaje
news:

On Tue, 3 Apr 2007 14:11:08 -0400, "Pedro" wrote:

Yo una vez probé con una base de datos de tamaño medio tirando a
pequeño y me fuí a tomar un café. Cuando volví me había generado casi
300.000 lineas y el IDE iba de pena.

La aplicación terminada no debería de tener mucho más de 20.000
líneas, y ya tenía 300.000 antes de empezar a programar.

Por curiosidad, ¿cuantas tablas y/o vistas metiste en ese dataset?

JJ,

Se supone que Crystal es "inteligente" :-) y transforma las fórmulas de
selección
en cláusulas WHERE cuando lo cree posible (comparaciones, fundamentalmente).
Si ve una llamada a una función del lenguaje de Crystal, ya no la transforma
y lo
hace todo en el cliente, con el aumento de tráfico y la pérdida de
rendimiento
consiguientes.

Por ejemplo, un consejo clásico de los libros de Crystal es que, si quieres
comprobar
si el nombre de un cliente empieza con 'A' (mayúscula o minúscula) utilices
la
fórmula:

{Clientes.Nombre} = 'A' or {Clientes.Nombre´} = 'a'

en vez de:

UpperCase({Clientes.Nombre}) = 'A'

porque en este último caso se traerá toda la tabla al cliente.

A partir de CR9 (la que viene con VS 2005 es la 10) ya no se puede
modificar la sentencia SQL, solo se puede ver, mediante la opción
Crystal Reports | Base de datos | Mostrar consulta SQL del menú.
Para compensar, existe la posibilidad de "Agregar comando", que no es
más que una sentencia SQL (o llamada a proc) escrita a mano por tí
completamente.

Slds - Octavio



"[Juanjo]" escribió en el mensaje
news:

Ok, Octavio,

Yo usaba las formulas de seleccion, por eso digo que traia todos los
datos,
y no "veia" el sitio donde poner el WHERE de la sentencia (por cierto,
puedes decir donde
se pone?), de hecho, "creo" que no se puede modificar la consulta SQL a
mano en
"ver texto de la consulta" (al menos en la version del VS2005).

Un saludo.

"Octavio Hernandez" escribió en el mensaje
news:

JJ,

Cuando haces un informe en Crystal, el Crystal no hace el "where"
sobre la base de datos, si no que trae todos los datos y luego hace el
filtro.

Te puedo asegurar que *NO* tienes razón en eso. Llevo entre una cosa y
otra 12-13 años
trabajando con Crystal, y desde Crystal 4.5 eso ya funcionaba.
Simplemente, el producto
no serviría para nada si no fuera capaz de "empujar" al servidor las
condiciones de selección
en la cláusula WHERE.

Si la base de datos contra la que Crystal está trabajando es SQL (no
hablo de Btrieve, dBase
o esas otras bases "de escritorio"), con la excepción que te menciono
debajo, Crystal pasa las
condiciones a la cláusula WHERE de la sentencia SQL (lo cual se puede ver
con la opción
"Ver texto de la consulta", que está ahí desde que recuerdo - antes se
podía incluso modificar
"a mano" la sentencia SQL).

La única excepción a esta regla es cuando en tu fórmula de selección
utilizas una FORMULA
DE CRYSTAL (una fórmula escrita en uno de los lenguajes de fórmulas que
tiene Crystal).
Claro, en ese caso él tiene que traerse los registros a local para
evaluar la fórmula ahí.

Slds - Octavio



"[Juanjo]" escribió en el mensaje
news:

Buenos dias:

Soy de las personas que piensan que una cosa no es mejor que otra o
peor, si no que puede
tener cosas buenas o mejores para unas cosas y peores o no tan buenas
para otras. Con esto
que quiero decir, por ejemplo: Un DataSet tipado es mejor que hacerlo a
mano? Es posible
que si o no. Cada uno tiene su experiencia. Es cierto que si tu miras el
fichero que gener el
Dataset.designer.cs tiene 1000 lineas (mas bien es 1000 lineas por cada
consulta) es cierto,
tambien es cierto que de las 1000 lineas, la mitad de ellas son
definiciones de tipos de datos, y la
otra mitad es la comprobacion de los parametros. Que mas da que tu
compruebes los parametros
o que los comprueben por ti??? Pues habra veces que interese no
comprobarlos, no se.

Respecto a los tipos de datos fuertemente tipados, que comenta Jose
Camacho, creo que
depende tambien del motor de la base de datos. Yo con tipo de dato fecha
no he tenido problema
en guardarla en un campo fecha sobre una base de datos SQL Server, pero
cuanto he tenido
que hacer una consulta "a pelo" sobre Access he tenido que cambiar el
orden de los dias, meses y años,
y sobre VFP ademas usar la funcion date.

Crystal y Visual Studio es para comer a parte, de hecho hay un hilo
mas abajo en el cual hay
una "especie de estudio" de como hacer mejor o peor una informe. Alguien
ha pensado si es un
problema entre el Crystal y el SQL Server por ejemplo? Vuelvo a comentar
un problema que he visto
en Crystal (porque lo he probado): Cuando haces un informe en Crystal,
el Crystal no hace el "where"
sobre la base de datos, si no que trae todos los datos y luego hace el
filtro (esto lo podeis ver si mostrais
la consulta que genera el Crystal, no lo estoy inventando, y las pruebas
las hice sobre 150.000 registros)
por esto mismo, yo personalmente, prefiero pasarle al crystal un dataset
tipado con los datos, para
que no tenga que hacer el Crystal la consulta.

No quiero decir que VC#, SQL Server y Crystal sea el mejor invento
despues de las patatas fritas con
huevos ni mucho menos. Yo cuando lo necesito uso los Dataset tipados y
cuando no, hago mi consulta a
pelo. Tampoco trato de convencer a nadie. Solo digo que cada uno use lo
que mejor le venga o interese
en cada momento, en ningun sitio esta escrito que te tengas que casar
con una forma de trabajar.

Un saludo.


"Pedro" escribió en el mensaje
news:

Alguien ha visto cuando uno agrega un dataset (y sus tablas) en un
formulario visualmente la cantidad de codigo que se genera internamente
en Dataset.designer.cs?
Pregunto, es necesario todo eso para trabajar con datos. Como le hago
si no quiero trabajar con dataset o por lo menos de esa manera?

Pedro

On Wed, 4 Apr 2007 15:46:01 +0200, "Juan Diego Bueno"
wrote:

Por curiosidad, ¿cuantas tablas y/o vistas metiste en ese dataset?

Apenas 200. Si hubiese seguido con los datasets tendría que haber
metido muchas más.


Saludos

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 4 Apr 2007 15:46:01 +0200, "Juan Diego Bueno"
wrote:

Por curiosidad, ¿cuantas tablas y/o vistas metiste en ese dataset?

Apenas 200. Si hubiese seguido con los datasets tendría que haber metido
muchas más.

Bueno, 200 tablas en un solo dataset (si lo hiciste así) me parece excesivo,
no sólo para este ÍDE, sino para cualquier otro. Lo suyo sería dividirlas en
diferentes datasets. Hay un término medio entre usar un dataset para cada
tabla y usar uno para 200, pero para gustos... Y por cierto, para que el IDE
casque no hace falta gran cosa, con menos ya da problemas

Creo que una vez dijiste que habías trabajado con Borland Delphi. De gente
que ha trabajado con ello, se que existe como una especie de contenedor de
datos (o algo así) donde se arrastraban los objetos de la base de datos al
estilo de los dataset. De ser así, ¿llegaste a probar a meter esas mismas
200 tablas y te iba bien el IDE?. ¿No generaba nada de código dicho
contenedor?

Saludos