Previous Thread:   .NET framework errormessage

1/23/2006 9:04:19 AM    Re: [NonSerialized]
"William Stacey [MVP]" <william.stacey@gmail.com> wrote in  
  
news:OLwgHuDIGHA.3064@TK2MSFTNGP10.phx.gbl:  
  
That'd imply a type which never would be stored inside SQL Server. For what  
  
purposes would you want such a thing?  
  
Niels  
  
--  
  
**************************************************  
  
* Niels Berglund  
  
* http://staff.develop.com/nielsb  
  
* nielsb@no-spam.develop.com  
  
* "A First Look at SQL Server 2005 for Developers"  
  
* http://www.awprofessional.com/title/0321180593  
  
**************************************************



1/23/2006 9:53:34 AM    Re: [NonSerialized]
"William Stacey [MVP]" <william.stacey@gmail.com> wrote in  
  
news:uU1guTEIGHA.668@TK2MSFTNGP11.phx.gbl:  
  
For an array, I'd say you still want to store it in the db. I see your  
  
scenario for a type with only statics. In that case, create a type as  
  
Format.Native and just give it one field. I know, it's a bit overkill,  
  
but...  
  
Niels  
  
--  
  
**************************************************  
  
* Niels Berglund  
  
* http://staff.develop.com/nielsb  
  
* nielsb@no-spam.develop.com  
  
* "A First Look at SQL Server 2005 for Developers"  
  
* http://www.awprofessional.com/title/0321180593  
  
**************************************************

1/23/2006 11:39:01 AM    [NonSerialized]
Why would they not support [NonSerialized] on a UDT?  
  
--  
  
William Stacey [MVP]

1/23/2006 11:56:50 AM    Re: [NonSerialized]
Hi William,  
  
There is no such thing in SQL Server as a memory-only datatype or a datatype  
  
that cannot be used as a column in a table.  And I believe that's  
  
essentially what you're asking for with this request.  If you need to do a  
  
lot of procedural logic in SQL Server, consider writing a CLR stored  
  
procedure or function.  That solution will perform a lot better than a  
  
non-serialized type would, which would still require marshalling data in and  
  
out of the CLR with every access to an instance of the type.  
  
--  
  
Adam Machanic  
  
Pro SQL Server 2005, available now  
  
http://www.apress.com/book/bookDisplay.html?bID=457  
  
--  
  
"William Stacey [MVP]" <william.stacey@gmail.com> wrote in message  
  
news:OLwgHuDIGHA.3064@TK2MSFTNGP10.phx.gbl...

1/23/2006 12:46:19 PM    Re: [NonSerialized]
Array/List type (i.e. string array, int array).  Type with only static  
  
members (i.e. File, Directory, etc).  Sometimes you may want a type, but  
  
don't really need it as a column type.  
  
--  
  
William Stacey [MVP]  
  
"Niels Berglund" <nielsb@develop.com> wrote in message  
  
news:Xns9754ADAA6C1C3nielsbdevelopcom@207.46.248.16...  
  
what

1/23/2006 12:51:11 PM    Re: [NonSerialized]
Hi Adam.  Not sure I see the perf difference between a CLR proc/func and a  
  
static method on a UDT?  They are all static members on a class or struct  
  
(in the case of UDTs).  What is the marshalling difference between say a clr  
  
func static method and udt static method?  
  
--  
  
William Stacey [MVP]  
  
"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message  
  
news:u%23GhE4DIGHA.1028@TK2MSFTNGP11.phx.gbl...  
  
datatype  
  
and

1/23/2006 1:20:51 PM    Re: [NonSerialized]
"William Stacey [MVP]" <william.stacey@gmail.com> wrote in message  
  
news:ehEwcWEIGHA.2628@TK2MSFTNGP15.phx.gbl...  
  
Same thing.  What you're describing is basically remoting.  Would you  
  
want to remote an array, or do all of the work on the array as locally as  
  
possible?  
  
--  
  
Adam Machanic  
  
Pro SQL Server 2005, available now  
  
http://www.apress.com/book/bookDisplay.html?bID=457  
  
--

1/23/2006 1:54:51 PM    Re: [NonSerialized]
Thanks Niels.  I thought about that as well.  AFAICT, this does not work as  
  
expected.  After calling any Mutator (such as AddItem()) the Read and Write  
  
methods get called.  So you will end up with an instance that only contains  
  
the stuff you serialized, hence lossing any other state.  Maybe, I am doing  
  
something wrong or could do a different way I don't see at the moment?  So  
  
that seems to mean you need to serialize/deserialize all state, which then  
  
also makes you hit the 8K max size.  So for things like List type, it would  
  
seem to be helpfull to add something like Format:None so it does not try to  
  
serialize/deserialize after each Add or Remove and you could support much  
  
more then 8K arrays (or other types).  
  
--  
  
William Stacey [MVP]

1/23/2006 2:06:58 PM    Re: [NonSerialized]
Maybe I misunderstood, but I was talking about your statement:  
  
"you need to do a lot of procedural logic in SQL Server, consider writing a  
  
CLR stored  
  
procedure or function.  That solution will perform a lot better than a  
  
non-serialized type would, which would still require marshalling data"  
  
In my mind there is no difference here.  Calling a method on a Type is no  
  
less performant then calling a CLR function.  
  
Are you talking about something else.  
  
--  
  
William Stacey [MVP]  
  
"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message  
  
news:up6VBnEIGHA.2696@TK2MSFTNGP14.phx.gbl...  
  
a  
  
struct

1/23/2006 2:26:05 PM    Re: [NonSerialized]
"William Stacey [MVP]" <william.stacey@gmail.com> wrote in message  
  
news:OG55yAFIGHA.2472@TK2MSFTNGP10.phx.gbl...  
  
From what I gather, you seem to be interested in using the same instance  
  
of the type iteratively in a procedure -- for instance, to use your array  
  
example, you might want to create the array, add a bunch of elements in a  
  
loop, then do something with those elements, one-by-one.  Doing this in the  
  
context of T-SQL calling into the CLR would mean that SQL Server would  
  
essentially have to remote your request over to the CLR on each iteration of  
  
the loop.  If you instead built that loop wholly within a CLR language, you  
  
would only have to incur the cost of remoting once..  
  
--  
  
Adam Machanic  
  
Pro SQL Server 2005, available now  
  
http://www.apress.com/book/bookDisplay.html?bID=457  
  
--