Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
C# / VFP8 tests
Message
De
15/07/2004 09:08:43
 
 
À
15/07/2004 08:54:52
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Visual FoxPro et .NET
Titre:
Divers
Thread ID:
00924570
Message ID:
00924636
Vues:
14
>Hi kevin,
>
>>>>>I suspect this is one of the pitfalls people could fall in when it seems difficult to get your data in a form that is directly usable in your front end, but this is really bad, bad practise.
>>>>
>>>>I'll rephrase that, the Database was designed badly and with useless naming conventions etc. and in some cases does not follow normalisation rules.
>>>>
>>>>What I meant is by today's standards the db could be looked at as a whole, because it's an old DB (12 years) it has had a lot of "crap" added to it with no regard as to how these alterations fit into the big picture.
>>>>
>>>>In other words, I would revisit the DB design as my chosen example DB is IMO fundamentally flawed in some areas.
>>>
>>>O.K. that makes things clear.
>>
>>I wander if the test will still be viable if the C# version used an SQL Server instead of Fox tables, you know, the whole Fox vs .Net+SQL Server lark....
>
>I don't think those test compare. If you're doing .NET/SQL server, you should compare it with VFP/SQL server. FYI, I don't think it is fruitfull to include the retrival of any data from the database in a comparison. I think we all agree now that there is not much of difference when retrieving data from a SQL server in .NET or VFP. Only the exception of when using large resultsets, in which .NET can become slugish. I think we should ignore that for now.

Good point, I thought that just after I sent the message as well....

>The real chalenge would be to see how C# processes data from one form to another out of one or two ADO recordsets and compare this with the performance and ease of its VFP equivalent. This IMO, is the real challange. Again IMO the link to my appointment scheduler example might be a good candidate. If there is not big difference in implementing this (Again from the POV of performance, ease of implementation, debugging and maintenance), then you've got a new .NET believer.

I've had a look at the example but it would really be easier for me to find an alternative that matches with my data (ie something that followings a similar example but matches with my existing data).

I'll keep looking.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform