Extra Space....

Hello!

I have written a report that is being displayed in a table. For some reason all the way to the right of the table has a HUGE amount of space......I checked to make sure there was no layers over it and I looked in the properties and saw no padding....ANY IDEAS? I am so frusterated because this defies all logic!!! Has anybody experienced this?

TIA!

That happened to me and I checked the width of the object that contained the table. In my case, the width of the rectangle that contained my table was way bigger than it should have been.|||

Oh Thank you for responding!! Are you talking about the width of the table itself....or the width of the page?

Thanks Again!

|||

Hi,

Check what the parent of the table is. If it says "body", then that is what you would adjust the width of.

|||Oh great! thanks!

external stored procedure (DLL) in Java?

Hi,

I am going to be writing an external stored procedure (my first) for SQL server 2000.

Has anyone out there written a DLL in Java (J++ or .NET) and then accessed the functions within the DLL as an external stored procedure in T/SQL?

I ask the question becaues I'm likely to get it done considerably faster if I write it in Java then VB ;-)

Any advice / suggestions most welcome.

Cheers,

EwanIt shouldn't really make a difference what language you write your dll in. As long as its compiled as a dll, you should be able to call it from a Stored Proc.

Just ensure that the dll is registered on the server that as executing the StoredProc (not the client).

As far as I know , there is no way to return values from the dll into the Stored Proc. Please let me know if there is.

I take no credit for the information below. I copied it from an old posting and saved it, and I cannot remember who posted it originally.

Good luck.

Lionel.

You can do it with the SP_OA* extened stored procedures, located in the
MASTER database (of ms-sql 7.0/2000). Look at this example (for sending
email
through jmail);

CREATE PROCEDURE sp_Send_JMail

@.fromName as char(50),
@.fromEmail as char(50),
@.toName as char(50),
@.toEmail as char(50),
@.subject as char(100),
@.Body as char(500)

AS
DECLARE @.ObjTok int
DECLARE @.RetVal int

EXEC @.RetVal=sp_OACreate'JMail.SMTPMail',@.ObjTok OUT
EXEC sp_OASetProperty @.ObjTok, 'ServerAddress','yourmailserver.com'
EXEC sp_OASetProperty @.ObjTok, 'SenderName', @.fromName
EXEC sp_OASetProperty @.ObjTok, 'Sender', @.fromEmail
EXEC sp_OASetProperty @.ObjTok,'Subject', @.Subject
EXEC @.RetVal = sp_OAMethod @.ObjTok, 'AddRecipient', Null,@.toEmail
EXEC sp_OASetProperty @.ObjTok, 'Body', @.Body
EXEC @.RetVal = sp_OAMethod @.ObjTok, 'Execute'
EXEC sp_OADestroy @.ObjTok GO

Extended Stored Procedures in SQL 2005?

The Extended Stored Procedures (Written in C++ unmanaged code) are supported in SQL Server 2005?

Thanks

Yes they are, but they are being deprecated.

Just out of curiousity; what are you writing that cannot be done in a .NET method, but needs an xp?

Niels

Extended stored procedures and UDP sockets

Hello,
I'm trying this question again; please excuse the repetition.
I have written an extended stored procedure using Visual C++ .Net
(unmanaged). The procedure is intended to send out a UDP multicast message
when new data arrives. The message doesn't seem to be sent.
I have verified that the ESP is getting called correctly (in response to an
INSERT trigger). I have verified that none of the Winsock API procedures
return errors when called from the ESP. I have verified the code that
actually sends the multicast message by running the exact same code from a
console application, where it works fine--including running it when logged i
n
under the account that SQL Server runs under.
There seems to be something unexpectedly different about the environment
that the ESP runs in. I'm at a loss to figure out what it is. Any clues
would be appreciated.
Thanks.
Ed Hoch
GEDDS Manager
Geophysical Institute
University of Alaska FairbanksI'll throw out some thoughts, though I don't have anything definite:
1. Are you initializing the Windows socket library right within the proc?
(I think it's WSAInitialize()). That definitely would need to be done.
2. If you can't get a solution, I know you could set a named Windows event
inside your extended proc (I've done that) and then have another process
waiting on that event and have it send the data gram.
3. Do you have fiber mode turned on in SQL Server? If so, that may affect
threading and sockets (just guessing...)
Mike
"Edward Hoch" <EdwardHoch@.discussions.microsoft.com> wrote in message
news:1A237FAF-EFD9-481B-99F8-6B05CCB3DA35@.microsoft.com...
> Hello,
> I'm trying this question again; please excuse the repetition.
> I have written an extended stored procedure using Visual C++ .Net
> (unmanaged). The procedure is intended to send out a UDP multicast
message
> when new data arrives. The message doesn't seem to be sent.
> I have verified that the ESP is getting called correctly (in response to
an
> INSERT trigger). I have verified that none of the Winsock API procedures
> return errors when called from the ESP. I have verified the code that
> actually sends the multicast message by running the exact same code from a
> console application, where it works fine--including running it when logged
in
> under the account that SQL Server runs under.
> There seems to be something unexpectedly different about the environment
> that the ESP runs in. I'm at a loss to figure out what it is. Any clues
> would be appreciated.
> Thanks.
> Ed Hoch
> --
> GEDDS Manager
> Geophysical Institute
> University of Alaska Fairbanks|||Hi Mike,
Thanks for the reply.
1. I am initializing the socket library with WSAStartup. It seems to work
from the console version of the program, so I think the initialization is
working properly.
2. Named events seem like a possibility. What's a good reference for
those?
3. I am not using the "Windows NT fibers" in my SQL Server. Would it be
more or less likely for the thing to work with fibers enabled?
Thanks again for the reply.
Ed Hoch
"Mike Jansen" wrote:

> I'll throw out some thoughts, though I don't have anything definite:
> 1. Are you initializing the Windows socket library right within the proc?
> (I think it's WSAInitialize()). That definitely would need to be done.
> 2. If you can't get a solution, I know you could set a named Windows event
> inside your extended proc (I've done that) and then have another process
> waiting on that event and have it send the data gram.
> 3. Do you have fiber mode turned on in SQL Server? If so, that may affect
> threading and sockets (just guessing...)
> Mike
> "Edward Hoch" <EdwardHoch@.discussions.microsoft.com> wrote in message
> news:1A237FAF-EFD9-481B-99F8-6B05CCB3DA35@.microsoft.com...
> message
> an
> in
>
>|||> Thanks for the reply.
> 1. I am initializing the socket library with WSAStartup. It seems to
work
> from the console version of the program, so I think the initialization is
> working properly.
WSAStartup, that was it :)

> 2. Named events seem like a possibility. What's a good reference for
> those?
In Windows API look at CreateEvent(), SetEvent(), OpenEvent(). I think
there's even an overview section on synchronization objects. The thing to
be aware of for named objects is that in order for them to work across
process boundaries you need to set up the SECURITY_ATTRIBUTES properly
(unless the other process happens to be running under the same account as
the SQL Server process). The named event won't pass any other context
information.
If you need to pass context information along with triggering an event, you
may want to do something like write out a file and have the process
monitoring a folder rather than an event. There are other options besides
files but file is simple and straightforward.
If you want more information, we can take this offline or to another group
since it's off-topic and can get fairly involved.

> 3. I am not using the "Windows NT fibers" in my SQL Server. Would it be
> more or less likely for the thing to work with fibers enabled?
Like I said, I was just guessing, but I'd guess you might have issues if
fibers were ENABLED a fiber is a "mutant" thread.
Also, perhaps you could try this (though I don't know if it's wise): In
your stored proc WinMain/on load, create a separate thread. Do your sockets
in that thread. That way it's still in the same process but on its own
thread. So your worker thread starts and waits for an item in a context
queue (something you create). When it receives an item in the queue, it
dequeues it and sends a datagram. In your exetended proc, just add items to
the queue. First, I'd do some scanning to see if secondary threads in
extended procs are OK. Regardless, the divantage of this is that its
starting to get complicated and complicated things mess up more often and
messing up inside the process space of SQL Server isn't the greatest thing.
So even if secondary threads are OK, BE VERY CAREFUL.
Mike|||What is the service account of SQL Server? Start the SQL Server service from
the command line, and execute the XP, see if that makes a difference.
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2005 All rights reserved.
"Edward Hoch" <EdwardHoch@.discussions.microsoft.com> wrote in message
news:1A237FAF-EFD9-481B-99F8-6B05CCB3DA35@.microsoft.com...
> Hello,
> I'm trying this question again; please excuse the repetition.
> I have written an extended stored procedure using Visual C++ .Net
> (unmanaged). The procedure is intended to send out a UDP multicast
> message
> when new data arrives. The message doesn't seem to be sent.
> I have verified that the ESP is getting called correctly (in response to
> an
> INSERT trigger). I have verified that none of the Winsock API procedures
> return errors when called from the ESP. I have verified the code that
> actually sends the multicast message by running the exact same code from a
> console application, where it works fine--including running it when logged
> in
> under the account that SQL Server runs under.
> There seems to be something unexpectedly different about the environment
> that the ESP runs in. I'm at a loss to figure out what it is. Any clues
> would be appreciated.
> Thanks.
> Ed Hoch
> --
> GEDDS Manager
> Geophysical Institute
> University of Alaska Fairbanks

Extended Stored Procedure: Get the current db of the client

Hi
Is there a way to get the current database of the client who calls my
Extended Stored Procedure?
I have written a DLL in Visual Studion 2005 for the SQL server 2003 in C/C++
using the functions srv_*.
Thanks.
HansWhat version of SQL Server?
It's a limitation of extended stored procedure programming
with SQL Server 2000. Some have tried using svr_rpcdb but it
will generally just return master as the database name. And
it's no longer supported.
-Sue
On Mon, 8 May 2006 14:41:59 +0200, "Hans Stoessel"
<hstoessel.list@.pm-medici.ch> wrote:

>Hi
>Is there a way to get the current database of the client who calls my
>Extended Stored Procedure?
>I have written a DLL in Visual Studion 2005 for the SQL server 2003 in C/C+
+
>using the functions srv_*.
>Thanks.
>Hans
>|||This never worked correctly, this is not way you can get the database
context from within an XP, easiest work around is to use a wrapper SP that
passes the db_name() or db_id() as a parameter.
In general using wrapper SP's is a good practice for doing parameter
validation, and meta data exposure since XP's do not emit the parameter
signatures.
GertD@.SQLDev.Net
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:feuv521gpm893g6hfi4aja0vpp8vguiun4@.
4ax.com...
> What version of SQL Server?
> It's a limitation of extended stored procedure programming
> with SQL Server 2000. Some have tried using svr_rpcdb but it
> will generally just return master as the database name. And
> it's no longer supported.
> -Sue
> On Mon, 8 May 2006 14:41:59 +0200, "Hans Stoessel"
> <hstoessel.list@.pm-medici.ch> wrote:
>
>|||Works for SP's, might work with XP's as well:
1. Prefix the name with "sp_"
2. Mark it as a system object with sp_MS_MarkSystemObject
This causes the SP to run under the context of the database it was called
from, not the master database where it resides. At the least, you can put
an SP wrapper in the master DB for the XP, and pass in the db_name() as a
parameter to the XP and it will have the correct database context (not
"master").
"Gert E.R. Drapers" <GertD@.SQLDev@.Net> wrote in message
news:%23ZtUJnzcGHA.3632@.TK2MSFTNGP05.phx.gbl...
> This never worked correctly, this is not way you can get the database
> context from within an XP, easiest work around is to use a wrapper SP that
> passes the db_name() or db_id() as a parameter.
> In general using wrapper SP's is a good practice for doing parameter
> validation, and meta data exposure since XP's do not emit the parameter
> signatures.
> GertD@.SQLDev.Net
>
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:feuv521gpm893g6hfi4aja0vpp8vguiun4@.
4ax.com...
>|||Does not matter, an XP does not have a call to retrieve the database
context.
GertD@.SQLDev.Net
"Mike C#" <xxx@.yyy.com> wrote in message news:wzR8g.505$Ut2.124@.fe09.lga...
> Works for SP's, might work with XP's as well:
> 1. Prefix the name with "sp_"
> 2. Mark it as a system object with sp_MS_MarkSystemObject
> This causes the SP to run under the context of the database it was called
> from, not the master database where it resides. At the least, you can put
> an SP wrapper in the master DB for the XP, and pass in the db_name() as a
> parameter to the XP and it will have the correct database context (not
> "master").
>
> "Gert E.R. Drapers" <GertD@.SQLDev@.Net> wrote in message
> news:%23ZtUJnzcGHA.3632@.TK2MSFTNGP05.phx.gbl...
>|||DBLIB, dbname() function.
http://msdn.microsoft.com/library/d...br />
2gtz.asp
enjoy
"Gert E.R. Drapers" <GertD@.SQLDev@.Net> wrote in message
news:u8i0W6WdGHA.4720@.TK2MSFTNGP03.phx.gbl...
> Does not matter, an XP does not have a call to retrieve the database
> context.
> GertD@.SQLDev.Net
> "Mike C#" <xxx@.yyy.com> wrote in message
> news:wzR8g.505$Ut2.124@.fe09.lga...
>|||No, because then you need to connect first! So what database do you
establish your connection to?
Please don't answer try to answer questions you do not know the answer to.
-GertD
"Mike C#" <xxx@.yyy.com> wrote in message news:Ga99g.60$Id.19@.fe10.lga...
> DBLIB, dbname() function.
> http://msdn.microsoft.com/library/d... />
z_2gtz.asp
> enjoy
> "Gert E.R. Drapers" <GertD@.SQLDev@.Net> wrote in message
> news:u8i0W6WdGHA.4720@.TK2MSFTNGP03.phx.gbl...
>|||And you plan to what? Put the same "wrapper" stored procedure in every
single database on a server?
Don't be a dick Gertrude.
"Gert E.R. Drapers" <GertD@.SQLDev@.Net> wrote in message
news:Ou6TvyjdGHA.3632@.TK2MSFTNGP05.phx.gbl...
> No, because then you need to connect first! So what database do you
> establish your connection to?
> Please don't answer try to answer questions you do not know the answer to.
> -GertD
> "Mike C#" <xxx@.yyy.com> wrote in message news:Ga99g.60$Id.19@.fe10.lga...
>|||underprocessable|||"Gert E.R. Drapers" wrote:

> No, you are incorrect; for an extended stored procedure you have to pass i
n
> the database context as a parameter if you need it, that is the only thing
> that works. Did you ever write an extended stored procedure?
I have written several, several, several extended stored procedures. In
fact, I just publicly released about 3 dozen that cover everything from AES,
Blowfish, Twofish, DES and TripleDES encryption to regular expressions to
recursively reading a local subdirectory listing.
In fact, here's a little experiment for you extended procedure maestro: Put
this regular stored procedure in the Master database:
CREATE PROCEDURE dbo.Test1
AS
SELECT db_Name()
GO
Now run it from within the Model database. Or the Northwind database. What
database name comes up? Master, that's what. According to your solution,
you need to recreate this exact same stored procedure in every single
database you own in order to get the current database context out of it.
As I said: changing the name to "sp_..." and marking it as a system object
will allow you to use JUST ONE copy of the stored procedure in Master. It
will run in the context of the CURRENT DATABASE, no matter what database you
invoke it from. But I'm sure you're well aware of that.

> Besides that it does not make sense to call the DB-Lib function dbname()
> untill you established a loopback connection over DB-Library, which would
> default to the default database for the user which is not the same as the
> database context. See the attached example which shows this behavior.
And that's all well and good. I was simply pointing out some things that
might be tried, and you pointed out that it wouldn't work in your own little
snide way.

> The srv_rpc* class methods in the OPENDS60.LIB file are obsolete since the
y
> are gateway calls and not longer supported; srv_rpcdb() only gave you a
> database context when you where a remote procedure, which is something
> different than an extended stored procedure, so that is not giving you wan
t
> you want either.
I know srv_rpcdb doesn't work, and didn't suggest it as a solution. I'm
sure whoever didn't know that will be happy to hear it from you, however.

> So Mike C#, the ONLY solution is to pass it in as a parameter!
Which is fine, and perfectly acceptable. The difference is simply this, if
you refer back to my original post: Your method requires the same stored
procedure be copied to all 28 of my databases. Alternatively I can put a
single copy in the Master database and be done with it.

> BTW: Next time you are calling somebody names you might want to check your
> facts before replying an making a fool out of yourself.
BTW: You should check your facts before you accuse someone of not having
any experience in your little domain over there before making a fool of
yourself.
http://www.sqlservercentral.com/col...oolkitpart1.asp
http://www.sqlservercentral.com/col...oolkitpart2.asp
http://www.sqlservercentral.com/col...oolkitpart3.asp
http://www.sqlservercentral.com/col...oolkitpart4.asp
Of course I'd love an opportunity to learn at the master's feet. So where
does Master Gert keep his extended procedures, that I may immerse myself in
the knowledge to be gained?sql

Extended Stored Procedure

I have written extend stored procedure using dblib.
declare @.p1 int
xp_myProc 'select * from table', @.p1 output.
This extended procedure exeute the query and generate the
xml. Using xp_prepardocument it generate the handle.
The output handle i want to use it another procedure to
read the value.
<anonymous@.discussions.microsoft.com> wrote in message
news:717501c47625$ef3aeb60$a401280a@.phx.gbl...
>I have written extend stored procedure using dblib.
> declare @.p1 int
> xp_myProc 'select * from table', @.p1 output.
> This extended procedure exeute the query and generate the
> xml. Using xp_prepardocument it generate the handle.
> The output handle i want to use it another procedure to
> read the value.
Are you having problems with the handle no longer being valid?
Bryant
|||Note that the handle is valid for the duration of a session. If your xp runs
in a different session context, the handle cannot be reused...
Best regards
Michael
"Bryant Likes" <bryant@.suespammers.org> wrote in message
news:%23mDquOsdEHA.712@.TK2MSFTNGP09.phx.gbl...
> <anonymous@.discussions.microsoft.com> wrote in message
> news:717501c47625$ef3aeb60$a401280a@.phx.gbl...
> Are you having problems with the handle no longer being valid?
> --
> Bryant
>

Expression Question

I am working on an aging report and am trying to sum one of the columns that
is the 30-60 Day bucket. I have the expression written as the following;
"=sum(fields!extcost.value) where (fields!interval.value>30 and
Fields!Interval.Value<=60)"
What logic should I be using?
Thank you,
Ryan2 ways to deal with this. In report cell:
=Sum(IIf(Fields!Interval.Value=>30 AND
Fields!Interval.value<=60,Fields!extcost.value,0))
However, I normally try to do this in the SQL with a CASE statement for each
bucket.
SELECT X,Y,Z,Sum(CASE WHEN Interval BETWEEN 30 and 60 THEN extcost ELSE 0
END As Bucket2,A,B,C...
FROM....
Michael C
"Ryan Mcbee" wrote:
> I am working on an aging report and am trying to sum one of the columns that
> is the 30-60 Day bucket. I have the expression written as the following;
> "=sum(fields!extcost.value) where (fields!interval.value>30 and
> Fields!Interval.Value<=60)"
> What logic should I be using?
> Thank you,
> Ryan
>

Exporting SQL Server Data

Hi,
We are migrating our website to a new hosting site. The site has a
CMS written in C# with a SQL Server backend. I need to migrate this
but the new hosting site will not allow me to restore the SQL Server
from backup at the new site and requires that I import CSV files.
How can I export the data to a CSV to import at the new hosting site?
Thank you very much.Hi
How about http://www.sqldts.com/299.aspx or you could use BCP and generate
the commands from sysobjects.
John
"KDawg44" <KDawg44@.gmail.com> wrote in message
news:74fd81da-6361-4544-aece-0330377841ce@.z38g2000hsc.googlegroups.com...
> Hi,
> We are migrating our website to a new hosting site. The site has a
> CMS written in C# with a SQL Server backend. I need to migrate this
> but the new hosting site will not allow me to restore the SQL Server
> from backup at the new site and requires that I import CSV files.
> How can I export the data to a CSV to import at the new hosting site?
> Thank you very much.