SQL Equivalent of Access OLE Object field
Hi
What is the SQL Equivalent of Access OLE Object field
What is the SQL Equivalent of Access OLE Object field
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Actually, I think the author should back up entirely and see why they were using the MS Access OLE Object. I suspect there is a far more elegant way to solve this problem then just saving all that binary data. If they are going to do that they may as well use Xml. :)
That last comment regarding Xml was said half in jest for Racim's benefit. I know he will get a kick out of it.
ASKER
Thanks very much
That last comment regarding Xml was said half in jest for Racim's benefit. I know he will get a kick out of it.
:)
Though I appreciate the intent, I'd have to say that benefit and xml have quasi mutually exclusive meanings, as far as I am concerned.
I invite you to read the following for more info...
http://workflow.healthbase.info/monographs/XML_myths_Browne.pdf
:)
Though I appreciate the intent, I'd have to say that benefit and xml have quasi mutually exclusive meanings, as far as I am concerned.
I invite you to read the following for more info...
http://workflow.healthbase.info/monographs/XML_myths_Browne.pdf
Racim,
You know we will never agree on the merits (or lack) of Xml. Certainly around that time when that article was written (2003) there was a lot of hype regarding Xml (as there is now IMHO with JSON), but if used wisely Xml has its place in the proverbial toolbox.
You know we will never agree on the merits (or lack) of Xml. Certainly around that time when that article was written (2003) there was a lot of hype regarding Xml (as there is now IMHO with JSON), but if used wisely Xml has its place in the proverbial toolbox.
You know we will never agree on the merits (or lack) of Xml.
Yes I know but I hope to change your mind someday :). No big deal.
The article underlines fundamental timeless flaws about the hierarchic structure of XML and hoping to get something out of this. I guess I came to the conclusion that living without it is better that living with it.
I am curious on what cases you consider to use XML wisely ? Since I don't use XML at all I may give it a shot and see.
Regards..
Yes I know but I hope to change your mind someday :). No big deal.
The article underlines fundamental timeless flaws about the hierarchic structure of XML and hoping to get something out of this. I guess I came to the conclusion that living without it is better that living with it.
I am curious on what cases you consider to use XML wisely ? Since I don't use XML at all I may give it a shot and see.
Regards..
In the past (prior to SQL Server 2008) I have used it very effectively to pass a dynamic list of parameters. The case where you you be passing one ID or several hundred. Another case is when you had a large list of optional parameters to be passed to a Stored Procedure for say searching purposes. These two use cases can now be replaced with Table Valued Parameters.
Another case, that is still valid is to use Xml in a Stored Procedure to create a comma delimited list.
Another case, that is still valid is to use Xml in a Stored Procedure to create a comma delimited list.
Hi acperkins,
little hint: This was also possible with SQL Server 2005 (and maybe before): Instead of using a table valued parameter simply create a temp table which is available in all called stored procedures without the need of a parameter. The lifetime of a temp table ends after the SP which created it. And it's an often heard myth that table valued parameters are all stored in memory - in fact SQL Server also creates temp tables for them so you have no disadvantage of creating a temp table in case of forwarding a parameter list.
Cheers,
Christian
little hint: This was also possible with SQL Server 2005 (and maybe before): Instead of using a table valued parameter simply create a temp table which is available in all called stored procedures without the need of a parameter. The lifetime of a temp table ends after the SP which created it. And it's an often heard myth that table valued parameters are all stored in memory - in fact SQL Server also creates temp tables for them so you have no disadvantage of creating a temp table in case of forwarding a parameter list.
Cheers,
Christian
This was also possible with SQL Server 2005 (and maybe before): Instead of using a table valued parameter simply create a temp table which is available in all called stored procedures without the need of a parameter.
Absolutely. I should have clarified when calling Stored Procedures from .NET and using SQL Server 2005 the only way was to use Xml (or God forbid) a delimited string.
Absolutely. I should have clarified when calling Stored Procedures from .NET and using SQL Server 2005 the only way was to use Xml (or God forbid) a delimited string.
http://msdn.microsoft.com/en-us/library/gg471497.aspx