Data Access API in Longhorn and Yukon

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The WinFS is a database. Therefore, why not making Data Access Code t
WinFS as similar to Data Access Code in Yukon and vise versa
I will list the issue in which code will require significant modificatio
when moving from one storage to another

1. "Each WinFS item type has a corresponding .NET Framework class which has System.Storage.Item in its hierarchy" - (Taken from http://msdn.microsoft.com/longhorn/...pull=/msdnmag/issues/04/01/WinFS/default.aspx

Why it is not the same for each SQL server (Yukon) type ??

2. All the following 3 quotation are taken from
"http://msdn.microsoft.com/events/pd...library/en-us/dnsql90/html/sql_ovyukondev.asp


"SQL types are a set of data types that are part of the .NET Runtime base class library. Unlike other data types in the .NET Runtime, which do not provide semantics such as NULL awareness, SQL types provide the same semantics and identical behavior as their corresponding native SQL Server data types.
Why WinFS type will not support NULL semantic

3. "You can use this support to send a command to SQL Server and request that a notification be generated if re-execution of the same command produces different results from those obtained initially. Commands sent to the server through any of the client APIs, such as ADO.NET, OLEDB, ODBC, ADO, and SOAP, may include a tag requiring a notification

Is such mechanism will be supported by WinFS ? It is the same API

4. "Microsoft .NET ObjectSpaces are a set of classes and interfaces that enable you to treat data as an object (or objects), independent of the underlying data store used by an application.

Does ObjectSpaces will be supported by WinFS ? It is the same API
 
You would have a better chance at getting an answer by posting this to
microsoft.public.windows.developer.winfx.winfs.

RE66 said:
The WinFS is a database. Therefore, why not making Data Access Code to
WinFS as similar to Data Access Code in Yukon and vise versa.
I will list the issue in which code will require significant modification
when moving from one storage to another:

1. "Each WinFS item type has a corresponding .NET Framework class which
Click to expand...
has System.Storage.Item in its hierarchy" - (Taken from
http://msdn.microsoft.com/longhorn/...pull=/msdnmag/issues/04/01/WinFS/default.aspx )
Why it is not the same for each SQL server (Yukon) type ???

2. All the following 3 quotation are taken from:
"http://msdn.microsoft.com/events/pdc/default.aspx?pull=/library/en-us/dnsql
90/html/sql_ovyukondev.asp"



"SQL types are a set of data types that are part of the .NET Runtime base
Click to expand...
class library. Unlike other data types in the .NET Runtime, which do not
provide semantics such as NULL awareness, SQL types provide the same
semantics and identical behavior as their corresponding native SQL Server
data types.
Why WinFS type will not support NULL semantic ?

3. "You can use this support to send a command to SQL Server and request
Click to expand...
that a notification be generated if re-execution of the same command
produces different results from those obtained initially. Commands sent to
the server through any of the client APIs, such as ADO.NET, OLEDB, ODBC,
ADO, and SOAP, may include a tag requiring a notification"
Is such mechanism will be supported by WinFS ? It is the same API ?

4. "Microsoft .NET ObjectSpaces are a set of classes and interfaces that
Click to expand...
enable you to treat data as an object (or objects), independent of the
underlying data store used by an application."
 
Thanks, but no thanks.
I have already done so and got ansered but since differant people in MS
look at fifferant NG I have wanted to expand
the readers
 
Why would you ask the same questions if you already have answers? The
answers aren't going to change simply because you posted it elsewhere...
 
The Longhorn newsgroups , especially the WinFX newsgroups, are the correct
place to ask these questions. The only people that are exposed to WinFX
(besides MS developers) are people that received the PDC Longhorn bits
either at PDC or thru MSDN Universal Subs. And those people will usually
frequent the correct groups for discussion and questions. WinFX is not
relevant to the current
DotNet Frameworks.
james
 
Back
Top