Data Access API in Longhorn and Yukon

[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

 

[Daniel O'Connell]

You would have a better chance at getting an answer by posting this to
microsoft.public.windows.developer.winfx.winfs.

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

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

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."

 

[Ron Efrati]

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

 

[Daniel O'Connell]

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...

 

[james]

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