Sql Advice: dll

Showing posts with label dll. Show all posts

Wednesday, March 21, 2012

Deployment

Hello,
What is the best way to deploy a Reporting Services solution. The solution
consists of database scripts, reports, CRI dll's and roles.
Thanks
HenrikHello Henrik,
I am not sure what does your solution include.
Based on my research and experience, you need to deploy those data
seperately.
For example, you need to run all the database scripts on the production
environment and then, you could use the VS 2005 IDE to deploy the report.
I am not sure what did you mean CRI dll and roles. Would you please specify
it more clearly?
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================(This posting is provided "AS IS", with no warranties, and confers no
rights.)|||Hello Wei Lu,
We have a solution that contains the following elements:
1) SQL Scripts, which create views, tables, ect.
2) Custom Report Items (CRI) which is contained in a DLL
3) Reports (RDL files)
4) Reporting Services User Roles
5) Datasources
6) Setup of policies (permissions) on each report
We have to package the solution and deploy it to multiple customers.
Best regards
Henrik.
"Wei Lu [MSFT]" <weilu@.online.microsoft.com> wrote in message
news:OnGVeBD7GHA.2336@.TK2MSFTNGXA01.phx.gbl...
> Hello Henrik,
> I am not sure what does your solution include.
> Based on my research and experience, you need to deploy those data
> seperately.
> For example, you need to run all the database scripts on the production
> environment and then, you could use the VS 2005 IDE to deploy the report.
> I am not sure what did you mean CRI dll and roles. Would you please
> specify
> it more clearly?
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>|||Have you looked at MSI packages?
You could probably package most of the elements. MSI packages can be used
for SQL scripts, which covers element 1, and might cover element 4, 5 and 6
if you can do this through SQL. It can also install dlls, covering element
2. I've never tried using msi against a web service, but it should be
possible, and with the right setup of your package, you should be able to
either deploy your reports or at least trigger a rss-script (reporting
services script, not the blog rss :) ) that will deploy your reports.
A bit of information here
http://www.sqlmag.com/Article/ArticleID/22428/sql_server_22428.html
A more hands-on example and article here
http://www.csharp-home.com/index/tiki-read_article.php?articleId=152
If you decide on msi, please tell the NG what you do and how successful it
turns out.
Kaisa M. Lindahl Lervik
"Henrik Skak Pedersen" <skak@.community.nospam> wrote in message
news:eY0e8DE7GHA.4116@.TK2MSFTNGP03.phx.gbl...
> Hello Wei Lu,
> We have a solution that contains the following elements:
> 1) SQL Scripts, which create views, tables, ect.
> 2) Custom Report Items (CRI) which is contained in a DLL
> 3) Reports (RDL files)
> 4) Reporting Services User Roles
> 5) Datasources
> 6) Setup of policies (permissions) on each report
> We have to package the solution and deploy it to multiple customers.
> Best regards
> Henrik.
>
> "Wei Lu [MSFT]" <weilu@.online.microsoft.com> wrote in message
> news:OnGVeBD7GHA.2336@.TK2MSFTNGXA01.phx.gbl...
>> Hello Henrik,
>> I am not sure what does your solution include.
>> Based on my research and experience, you need to deploy those data
>> seperately.
>> For example, you need to run all the database scripts on the production
>> environment and then, you could use the VS 2005 IDE to deploy the report.
>> I am not sure what did you mean CRI dll and roles. Would you please
>> specify
>> it more clearly?
>> Sincerely,
>> Wei Lu
>> Microsoft Online Community Support
>> ==================================================>> Get notification to my posts through email? Please refer to
>> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
>> ications.
>> Note: The MSDN Managed Newsgroup support offering is for non-urgent
>> issues
>> where an initial response from the community or a Microsoft Support
>> Engineer within 1 business day is acceptable. Please note that each
>> follow
>> up response may take approximately 2 business days as the support
>> professional working with you may need further investigation to reach the
>> most efficient resolution. The offering is not appropriate for situations
>> that require urgent, real-time or phone-based interactions or complex
>> project analysis and dump analysis issues. Issues of this nature are best
>> handled working with a dedicated Microsoft Support Engineer by contacting
>> Microsoft Customer Support Services (CSS) at
>> http://msdn.microsoft.com/subscriptions/support/default.aspx.
>> ==================================================>> (This posting is provided "AS IS", with no warranties, and confers no
>> rights.)
>|||Hello Henrik,
I agreee with Kaisa.
You could setup a MSI package to deploy the SQL Script and use the RSS
script to deploy the Report.
Here are also some article for your reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/ht
ml/vbtskcreatinginstallerforyourapplication.asp
http://www.codeproject.com/dotnet/Win_App_Setup_Project.asp?df=100&forumid=2
50630&exp=0&select=1419048
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rsprog/htm/
rsp_prog_soapapi_script_3ik1.asp
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.

Sunday, March 11, 2012

Deploying SMO

Hello,

I am writing a commercial client application for SQL server 2000/2005 and probably I am going to use SMO dll's.

I would like to know if there is any restriction in order to deploy SMO objects with my software. Are they free? and moreover is possible to deploy only those dll's that i actually need, without installing the whole redist package.

thank you in advance!

Zoran Maksimovic

See http://blogs.msdn.com/mwories/articles/smofaq.aspx which contains a link to the SMO redist. This page also contains limitations (but you should be generally be free to redistribute it with your application).

Deploying SMO

Hello,

I am writing a commercial client application for SQL server 2000/2005 and probably I am going to use SMO dll's.

thank you in advance!

Zoran Maksimovic

Friday, March 9, 2012

deploying extended stored proc

Hi
I have written an extended stored procedure DLL, thanks to the people who
helped me on this.
however i wonder if anyone could shed any light on my deployment issues that
I'm having with it.
Basically, I built it on my XP development PC with VC7.1. I can deploy it on
this PC's local default instance of MSDE without problems. It uses no managed
code whatsoever, and is compiled without /clr. Totally unmanaged.
I am trying to deploy it to a different PC with Win2K, and again - a local,
default, instance of MSDE. I copied it to C:\program files\microsoft sql
server\mssql\binn just as on my pc, added it using "sp_addextendedproc
'xp_myproc', 'xp_myproc.dll'", but it gave the error:
ODBC: Msg 0, Level 16, State 1
Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
126(error not found).
The only thing I can think to be different is that one's got Win2000,
whereas my dev. PC has got XP. This shouldn't matter though, should it?
I checked that the names are the correct case, correct names of the
procedure and the DLL filename and everything.
What could be wrong?
ThanksSorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
server?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bonj" <Bonj@.discussions.microsoft.com> wrote in message
news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> Hi
> I have written an extended stored procedure DLL, thanks to the people who
> helped me on this.
> however i wonder if anyone could shed any light on my deployment issues that
> I'm having with it.
> Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> this PC's local default instance of MSDE without problems. It uses no managed
> code whatsoever, and is compiled without /clr. Totally unmanaged.
> I am trying to deploy it to a different PC with Win2K, and again - a local,
> default, instance of MSDE. I copied it to C:\program files\microsoft sql
> server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> ODBC: Msg 0, Level 16, State 1
> Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> 126(error not found).
> The only thing I can think to be different is that one's got Win2000,
> whereas my dev. PC has got XP. This shouldn't matter though, should it?
> I checked that the names are the correct case, correct names of the
> procedure and the DLL filename and everything.
> What could be wrong?
> Thanks
>|||Nope. Like I say, the following is true of both dev machine, and deployment
target:
There's only one, default, instance of SQL Server (MSDE) on the machine. The
path of the binaries is
c:\program files\microsoft sql server\mssql\binn
and this is the only location where sqlservr.exe is found on the machine.
"Tibor Karaszi" wrote:
> Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> server?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > Hi
> > I have written an extended stored procedure DLL, thanks to the people who
> > helped me on this.
> > however i wonder if anyone could shed any light on my deployment issues that
> > I'm having with it.
> > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > this PC's local default instance of MSDE without problems. It uses no managed
> > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > ODBC: Msg 0, Level 16, State 1
> > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > 126(error not found).
> >
> > The only thing I can think to be different is that one's got Win2000,
> > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> >
> > I checked that the names are the correct case, correct names of the
> > procedure and the DLL filename and everything.
> >
> > What could be wrong?
> >
> > Thanks
> >
>
>|||I see, it was only a wild guess...
Re-reading the error message, it can also be that the DLL you produced in return references some
other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
here... :-\).
I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
problem might be. Perhaps some of the VC persons can pick up on that. ;-)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bonj" <Bonj@.discussions.microsoft.com> wrote in message
news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> Nope. Like I say, the following is true of both dev machine, and deployment
> target:
> There's only one, default, instance of SQL Server (MSDE) on the machine. The
> path of the binaries is
> c:\program files\microsoft sql server\mssql\binn
> and this is the only location where sqlservr.exe is found on the machine.
>
> "Tibor Karaszi" wrote:
> > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> > server?
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > Hi
> > > I have written an extended stored procedure DLL, thanks to the people who
> > > helped me on this.
> > > however i wonder if anyone could shed any light on my deployment issues that
> > > I'm having with it.
> > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > this PC's local default instance of MSDE without problems. It uses no managed
> > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > ODBC: Msg 0, Level 16, State 1
> > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > 126(error not found).
> > >
> > > The only thing I can think to be different is that one's got Win2000,
> > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > >
> > > I checked that the names are the correct case, correct names of the
> > > procedure and the DLL filename and everything.
> > >
> > > What could be wrong?
> > >
> > > Thanks
> > >
> >
> >
> >|||Like I say, it does it the same with a 'blank' extended stored procedure...
i.e. just let the wizard create one, don't add any code, and compile. That
doesn't work on it either.
"Tibor Karaszi" wrote:
> I see, it was only a wild guess...
> Re-reading the error message, it can also be that the DLL you produced in return references some
> other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
> here... :-\).
> I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
> problem might be. Perhaps some of the VC persons can pick up on that. ;-)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> > Nope. Like I say, the following is true of both dev machine, and deployment
> > target:
> > There's only one, default, instance of SQL Server (MSDE) on the machine. The
> > path of the binaries is
> > c:\program files\microsoft sql server\mssql\binn
> > and this is the only location where sqlservr.exe is found on the machine.
> >
> >
> > "Tibor Karaszi" wrote:
> >
> > > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> > > server?
> > >
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > http://www.karaszi.com/sqlserver/default.asp
> > > http://www.solidqualitylearning.com/
> > >
> > >
> > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > > Hi
> > > > I have written an extended stored procedure DLL, thanks to the people who
> > > > helped me on this.
> > > > however i wonder if anyone could shed any light on my deployment issues that
> > > > I'm having with it.
> > > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > > this PC's local default instance of MSDE without problems. It uses no managed
> > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > > ODBC: Msg 0, Level 16, State 1
> > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > > 126(error not found).
> > > >
> > > > The only thing I can think to be different is that one's got Win2000,
> > > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > > >
> > > > I checked that the names are the correct case, correct names of the
> > > > procedure and the DLL filename and everything.
> > > >
> > > > What could be wrong?
> > > >
> > > > Thanks
> > > >
> > >
> > >
> > >
>
>|||Possibly some stuff is linked in by the compiling environment. I haven't used C or C++ for some 12
years now, so this is only a guess...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bonj" <Bonj@.discussions.microsoft.com> wrote in message
news:67E3A9A6-3BC7-4110-9188-8FC3996555A8@.microsoft.com...
> Like I say, it does it the same with a 'blank' extended stored procedure...
> i.e. just let the wizard create one, don't add any code, and compile. That
> doesn't work on it either.
>
> "Tibor Karaszi" wrote:
> > I see, it was only a wild guess...
> >
> > Re-reading the error message, it can also be that the DLL you produced in return references some
> > other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
> > here... :-\).
> >
> > I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
> > problem might be. Perhaps some of the VC persons can pick up on that. ;-)
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> > > Nope. Like I say, the following is true of both dev machine, and deployment
> > > target:
> > > There's only one, default, instance of SQL Server (MSDE) on the machine. The
> > > path of the binaries is
> > > c:\program files\microsoft sql server\mssql\binn
> > > and this is the only location where sqlservr.exe is found on the machine.
> > >
> > >
> > > "Tibor Karaszi" wrote:
> > >
> > > > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of
SQL
> > > > server?
> > > >
> > > > --
> > > > Tibor Karaszi, SQL Server MVP
> > > > http://www.karaszi.com/sqlserver/default.asp
> > > > http://www.solidqualitylearning.com/
> > > >
> > > >
> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > > > Hi
> > > > > I have written an extended stored procedure DLL, thanks to the people who
> > > > > helped me on this.
> > > > > however i wonder if anyone could shed any light on my deployment issues that
> > > > > I'm having with it.
> > > > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > > > this PC's local default instance of MSDE without problems. It uses no managed
> > > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > > > ODBC: Msg 0, Level 16, State 1
> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > > > 126(error not found).
> > > > >
> > > > > The only thing I can think to be different is that one's got Win2000,
> > > > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > > > >
> > > > > I checked that the names are the correct case, correct names of the
> > > > > procedure and the DLL filename and everything.
> > > > >
> > > > > What could be wrong?
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >|||As you suggested I created a default extended stored procedure using
VS.NET'03 on WinXP...I used the depends.exe to determine the dependencies.
Depends.exe reported and error trying to find the OPENDS60.DLL. Perhaps this
is part of your problem...
"Bonj" wrote:
> Like I say, it does it the same with a 'blank' extended stored procedure...
> i.e. just let the wizard create one, don't add any code, and compile. That
> doesn't work on it either.
>
> "Tibor Karaszi" wrote:
> > I see, it was only a wild guess...
> >
> > Re-reading the error message, it can also be that the DLL you produced in return references some
> > other DLL file, and this is the file that cannot be found. (I'm sorry if I'm stating the obvious
> > here... :-\).
> >
> > I'm sure that there are tools out there to check DLL dependencies etc to investigate what the
> > problem might be. Perhaps some of the VC persons can pick up on that. ;-)
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
> > > Nope. Like I say, the following is true of both dev machine, and deployment
> > > target:
> > > There's only one, default, instance of SQL Server (MSDE) on the machine. The
> > > path of the binaries is
> > > c:\program files\microsoft sql server\mssql\binn
> > > and this is the only location where sqlservr.exe is found on the machine.
> > >
> > >
> > > "Tibor Karaszi" wrote:
> > >
> > > > Sorry for the obvious question, but perhaps you added the dll file for the wrong instance of SQL
> > > > server?
> > > >
> > > > --
> > > > Tibor Karaszi, SQL Server MVP
> > > > http://www.karaszi.com/sqlserver/default.asp
> > > > http://www.solidqualitylearning.com/
> > > >
> > > >
> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
> > > > > Hi
> > > > > I have written an extended stored procedure DLL, thanks to the people who
> > > > > helped me on this.
> > > > > however i wonder if anyone could shed any light on my deployment issues that
> > > > > I'm having with it.
> > > > > Basically, I built it on my XP development PC with VC7.1. I can deploy it on
> > > > > this PC's local default instance of MSDE without problems. It uses no managed
> > > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
> > > > > I am trying to deploy it to a different PC with Win2K, and again - a local,
> > > > > default, instance of MSDE. I copied it to C:\program files\microsoft sql
> > > > > server\mssql\binn just as on my pc, added it using "sp_addextendedproc
> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
> > > > > ODBC: Msg 0, Level 16, State 1
> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it references. Reason:
> > > > > 126(error not found).
> > > > >
> > > > > The only thing I can think to be different is that one's got Win2000,
> > > > > whereas my dev. PC has got XP. This shouldn't matter though, should it?
> > > > >
> > > > > I checked that the names are the correct case, correct names of the
> > > > > procedure and the DLL filename and everything.
> > > > >
> > > > > What could be wrong?
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >|||oh right... i'll check it out when I get back to work..
Cheers for the investigation, appreciate it!
"Mike M" <Mike M@.discussions.microsoft.com> wrote in message
news:D91F9749-AED1-44C0-9AA0-6251A39EE6B2@.microsoft.com...
> As you suggested I created a default extended stored procedure using
> VS.NET'03 on WinXP...I used the depends.exe to determine the dependencies.
> Depends.exe reported and error trying to find the OPENDS60.DLL. Perhaps
> this
> is part of your problem...
> "Bonj" wrote:
>> Like I say, it does it the same with a 'blank' extended stored
>> procedure...
>> i.e. just let the wizard create one, don't add any code, and compile.
>> That
>> doesn't work on it either.
>>
>> "Tibor Karaszi" wrote:
>> > I see, it was only a wild guess...
>> >
>> > Re-reading the error message, it can also be that the DLL you produced
>> > in return references some
>> > other DLL file, and this is the file that cannot be found. (I'm sorry
>> > if I'm stating the obvious
>> > here... :-\).
>> >
>> > I'm sure that there are tools out there to check DLL dependencies etc
>> > to investigate what the
>> > problem might be. Perhaps some of the VC persons can pick up on that.
>> > ;-)
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
>> > > Nope. Like I say, the following is true of both dev machine, and
>> > > deployment
>> > > target:
>> > > There's only one, default, instance of SQL Server (MSDE) on the
>> > > machine. The
>> > > path of the binaries is
>> > > c:\program files\microsoft sql server\mssql\binn
>> > > and this is the only location where sqlservr.exe is found on the
>> > > machine.
>> > >
>> > >
>> > > "Tibor Karaszi" wrote:
>> > >
>> > > > Sorry for the obvious question, but perhaps you added the dll file
>> > > > for the wrong instance of SQL
>> > > > server?
>> > > >
>> > > > --
>> > > > Tibor Karaszi, SQL Server MVP
>> > > > http://www.karaszi.com/sqlserver/default.asp
>> > > > http://www.solidqualitylearning.com/
>> > > >
>> > > >
>> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
>> > > > > Hi
>> > > > > I have written an extended stored procedure DLL, thanks to the
>> > > > > people who
>> > > > > helped me on this.
>> > > > > however i wonder if anyone could shed any light on my deployment
>> > > > > issues that
>> > > > > I'm having with it.
>> > > > > Basically, I built it on my XP development PC with VC7.1. I can
>> > > > > deploy it on
>> > > > > this PC's local default instance of MSDE without problems. It
>> > > > > uses no managed
>> > > > > code whatsoever, and is compiled without /clr. Totally unmanaged.
>> > > > > I am trying to deploy it to a different PC with Win2K, and
>> > > > > again - a local,
>> > > > > default, instance of MSDE. I copied it to C:\program
>> > > > > files\microsoft sql
>> > > > > server\mssql\binn just as on my pc, added it using
>> > > > > "sp_addextendedproc
>> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
>> > > > > ODBC: Msg 0, Level 16, State 1
>> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it
>> > > > > references. Reason:
>> > > > > 126(error not found).
>> > > > >
>> > > > > The only thing I can think to be different is that one's got
>> > > > > Win2000,
>> > > > > whereas my dev. PC has got XP. This shouldn't matter though,
>> > > > > should it?
>> > > > >
>> > > > > I checked that the names are the correct case, correct names of
>> > > > > the
>> > > > > procedure and the DLL filename and everything.
>> > > > >
>> > > > > What could be wrong?
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > >
>> > > >
>> > > >
>> >
>> >
>> >|||I ran depends.exe on it and it said this at the bottom in red:
Warning: At least one module has an unresolved import due to a missing
export function in a delay-load dependent module.
How can I find which one, and resolve it?|||It didn't seem to be the opends60.dll, because the target machine has got it
in its SQL server "binn" directory.
"Bonj" <benjtaylor at hotpop d0t com> wrote in message
news:uXSnkr5tEHA.2072@.tk2msftngp13.phx.gbl...
> oh right... i'll check it out when I get back to work..
> Cheers for the investigation, appreciate it!
> "Mike M" <Mike M@.discussions.microsoft.com> wrote in message
> news:D91F9749-AED1-44C0-9AA0-6251A39EE6B2@.microsoft.com...
>> As you suggested I created a default extended stored procedure using
>> VS.NET'03 on WinXP...I used the depends.exe to determine the
>> dependencies.
>> Depends.exe reported and error trying to find the OPENDS60.DLL. Perhaps
>> this
>> is part of your problem...
>> "Bonj" wrote:
>> Like I say, it does it the same with a 'blank' extended stored
>> procedure...
>> i.e. just let the wizard create one, don't add any code, and compile.
>> That
>> doesn't work on it either.
>>
>> "Tibor Karaszi" wrote:
>> > I see, it was only a wild guess...
>> >
>> > Re-reading the error message, it can also be that the DLL you produced
>> > in return references some
>> > other DLL file, and this is the file that cannot be found. (I'm sorry
>> > if I'm stating the obvious
>> > here... :-\).
>> >
>> > I'm sure that there are tools out there to check DLL dependencies etc
>> > to investigate what the
>> > problem might be. Perhaps some of the VC persons can pick up on that.
>> > ;-)
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > news:18370E98-D316-4A4C-B5D7-BCCD553AC4FD@.microsoft.com...
>> > > Nope. Like I say, the following is true of both dev machine, and
>> > > deployment
>> > > target:
>> > > There's only one, default, instance of SQL Server (MSDE) on the
>> > > machine. The
>> > > path of the binaries is
>> > > c:\program files\microsoft sql server\mssql\binn
>> > > and this is the only location where sqlservr.exe is found on the
>> > > machine.
>> > >
>> > >
>> > > "Tibor Karaszi" wrote:
>> > >
>> > > > Sorry for the obvious question, but perhaps you added the dll file
>> > > > for the wrong instance of SQL
>> > > > server?
>> > > >
>> > > > --
>> > > > Tibor Karaszi, SQL Server MVP
>> > > > http://www.karaszi.com/sqlserver/default.asp
>> > > > http://www.solidqualitylearning.com/
>> > > >
>> > > >
>> > > > "Bonj" <Bonj@.discussions.microsoft.com> wrote in message
>> > > > news:A412072A-1157-4908-8D07-96CDBE6788AC@.microsoft.com...
>> > > > > Hi
>> > > > > I have written an extended stored procedure DLL, thanks to the
>> > > > > people who
>> > > > > helped me on this.
>> > > > > however i wonder if anyone could shed any light on my deployment
>> > > > > issues that
>> > > > > I'm having with it.
>> > > > > Basically, I built it on my XP development PC with VC7.1. I can
>> > > > > deploy it on
>> > > > > this PC's local default instance of MSDE without problems. It
>> > > > > uses no managed
>> > > > > code whatsoever, and is compiled without /clr. Totally
>> > > > > unmanaged.
>> > > > > I am trying to deploy it to a different PC with Win2K, and
>> > > > > again - a local,
>> > > > > default, instance of MSDE. I copied it to C:\program
>> > > > > files\microsoft sql
>> > > > > server\mssql\binn just as on my pc, added it using
>> > > > > "sp_addextendedproc
>> > > > > 'xp_myproc', 'xp_myproc.dll'", but it gave the error:
>> > > > > ODBC: Msg 0, Level 16, State 1
>> > > > > Cannot load the DLL xp_myproc.dll, or one of the DLLs it
>> > > > > references. Reason:
>> > > > > 126(error not found).
>> > > > >
>> > > > > The only thing I can think to be different is that one's got
>> > > > > Win2000,
>> > > > > whereas my dev. PC has got XP. This shouldn't matter though,
>> > > > > should it?
>> > > > >
>> > > > > I checked that the names are the correct case, correct names of
>> > > > > the
>> > > > > procedure and the DLL filename and everything.
>> > > > >
>> > > > > What could be wrong?
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > >
>> > > >
>> > > >
>> >
>> >
>> >
>

Saturday, February 25, 2012

deploy to another server

I do not have access to VS, but I hear it can do this... how can I do it without VS?

I am using CREATE ASSEMBLY to load dll form my server to SQLServer on my server (Same machine). How can I load the dll to another server? Do I have to write it on a directory on that server first? I tried to run the command from my pc connected to the other server, and I get a "cannot find file" error.

The FROM clause in CREATE ASSEMBLY can either take a path to the dll (which is what you are doing), but it can also instead of the path take the binary representation of the dll.

So in your case, you can either use a path which the remote server accesses and has permissions to - or you can take the binary representation of the assembly instead.

Niels

|||Thanks. How do I do that binary representation? All the documentation I see is about the path to the dll. I'm new to .net development so I don't know where to go for help.|||

The syntax is

CREATE ASSEMBLY <asm_name> FROM 0x...

where 0x... is the hex binary representation.

The simplest way to get this is the use Management Studio. Choose the assembly in the object explorer, and click Script Assembly As -> Create To > New Query Editor Window. This will output the right syntax for you.

An alternative is code like below to convert the assembly to binary.

using System.IO;

using System;

using System.Text;

public class FileToHexBinary

{

public static void Main(String[] args)

{

FileStream fs = new FileStream(args[0], FileMode.Open);

int size = (int)fs.Length;

byte[] bytes = new byte [size];

fs.Read (bytes, 0, size);

fs.Close ();

StringBuilder builder = new StringBuilder(size * 2);

foreach( byte b in bytes)

{

builder.Append(b.ToString("x2"));

}

Console.WriteLine("0x" + builder.ToString());

}

|||Why b.ToString("x2")? What does the x2 mean? Whats the difference between "x" and "x2"?

Wednesday, March 21, 2012

Deployment

Sunday, March 11, 2012

Deploying SMO

Deploying SMO

Friday, March 9, 2012

deploying extended stored proc

deploying extended stored proc

deploying extended stored proc

Saturday, February 25, 2012

deploy to another server

Sql Advice

Blog Archive

About Me