Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFPConversion Seminar - May 9-10 - Dallas, TX
Message
From
17/04/2005 14:04:02
Walter Meester
HoogkarspelNetherlands
 
 
To
16/04/2005 11:09:59
General information
Forum:
Visual FoxPro
Category:
Conferences & events
Miscellaneous
Thread ID:
01002513
Message ID:
01005611
Views:
36
Hi bonnie,

I've got to disagree with you on this one.

I've got fundamental issues with using stored procs (e.g. not cross platform, database depended, so not flexible). I'd rather use SPT for the things I'm doing.

I find in the apps I'm building I'm doing a lot of SQL construction on the fly (which is rooted in the high level of data driven validation rules, queries, and business logic) in which case SPT is the only choice. I Try to limit the SPs to a minimum, (avoiding the database to become part of the products logic or applications specific data access).

I'm also using a lot of remote views in which case of course you can use typed datasets.
It seems that in .NET I'll have to deal with two different dataacess methodologies, typed and untyped datasets.

Walter,


>Walter,

>We use Typed DataSets exclusively in our .NET app. One should know beforehand what result-set they are expecting to get back from the database. We never build SQL statements on the fly. IMHO, all data access should be through Stored Procs (we use a SQL Server backend).

>~~Bonnie

>
>>Hi kevin,
>>
>>>I have one thing to add to this. How about database access ?? It seems more or less going through a same mechanism where you have to interface between fields of which you don't know the exact type and the strong typed variables in the language. How does the compiler handle that, since it cannot determine the type of a field at compile time ??
>>
>>
>>>Typed datasets that correspond to your data might be one answer. The compiler can enforce data types, so long as you reference the field as an object (e.g. MyDataSet.MyTable[0].MyField).
>>
>>Thanks, I've seen this before (I think I've read that message somewhere in the past, or was it a MSDN article ?). But of course in practise things might be different. When doing database access your never be sure what gets returned by a SQL SELECT * statement or a stored procedure. The compiler has of course then has now way of knowing of what type a certain field is. So what happens if a field is added or removed to the resultset. Does the program blow up or has it a more intelligent way of resolving the issue ?? Typed datasets of course can be a very valid answer in a lot of cases, though it might require a bit more maintenance. But in case you're building up a SQL statement on the fly where the field list can be dynamic, typed datasets seem to be a less attractive option IMO.
>>
>>Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform