July 19, 2011 at 11:24 am
Ooo, thats an interesting idea.. How about external activation with service broker, that could break the 32/64 problem I think.
Oh, wait, I see the OP has to cut research short.. Hate those pesky deadlines.
CEWII
July 19, 2011 at 11:38 am
Doesn't mean we can't discuss it...John will be back later if performance concerns outweigh the next deadline.
SB crossed my mind too. I was thinking of external activation calling a compiled .NET Console App and using the return code to get data back...but the requirements about what the results of the calc dll functions will look like (may need multiple apps to wrap different functions, and console apps are restricted to int on return codes) and whether SB can be made to work close enough to synchronously for this use case to be useful...head was spinning plus I thought IPC might be faster. SB with a console app might be quicker to market though if you can get it to work.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
July 19, 2011 at 12:55 pm
I downloaded the stuff to do an Ext activation process. I'm excited to try it.
CEWII
July 20, 2011 at 8:58 am
Glad you found the 64bit problem - I was going to post that when I saw the top part of the thread - I haven't really ever used SQLCLR (too old school I guess but I don't really like the idea of running .Net framework as a sproc) - but had a similar problem for an ordinary .Net app which needed to use some API libraries that were 32bit only - when running on 64 bit machine it failed to load them - trick was to set the "Build" Platform target on the properties of the Visual Studio project to x86 rather than "Any CPU" then .Net ran it as 32bit. Not sure if that is an option you could change in SQLCLR
James Horsley
Workflow Consulting Limited
July 20, 2011 at 9:41 am
That definitely is an option in the SQLCLR project, but isn't a solution since it causes the whole assembly to be unloadable in SQL Server. The full error is quoted below, but basically is boils down to the assembly's codebase being is invalid. Nice try though; I'd love a simple solution.
Msg 10314, Level 16, State 11, Line 2
An error occurred in the Microsoft .NET Framework while trying to load assembly id 65755. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:
System.IO.FileLoadException: Could not load file or assembly 'spm_calc_tvf, Version=7.1.0.1, Culture=neutral, PublicKeyToken=edf61be8e5e97d7d' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
System.IO.FileLoadException:
at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
July 20, 2011 at 10:28 am
Maybe this will help
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/#more-355
James Horsley
Workflow Consulting Limited
July 20, 2011 at 11:49 am
James Horsley (7/20/2011)
Maybe this will helphttp://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/#more-355
Thanks James. I'm keeping a copy of that article for when I have time to revisit the issue.
Viewing 7 posts - 31 through 36 (of 36 total)
You must be logged in to reply to this topic. Login to reply