Ok, now here's an easy one...

Programic render of a report to PDF, how to remove my html, and or render to a
pdf w/out my param controls?
Can I call a NewWindow? or what should I do?
I've overcome how to pass a .Net dataset to a SSRS report, smoke & mirrors, it
is a kluge but I've got it working.
It wasn't much code just'a diff'rent way o'do'in it...
Anyway, my pain.
On my web page when I call w/rs.render my report to html I get my report at top
of the page and my one paramerter textbox and cmd button, no problem.
However, when I render to PDF, .Net Dev opens and I get trash back.
When I save to disk I get trash, but if I rename and edit in Notepad, strip out
everything after the EOF, basically all the html, I get a viable PDF.Ok, I found the Example Sample FindSavePrint....
I just thought that it'd be simpler....
I streamed it....
TIA
JeffP....
"JDP@.Work" <JPGMTNoSpam@.sbcglobal.net> wrote in message
news:uZdyHO4bEHA.252@.TK2MSFTNGP10.phx.gbl...
> Programic render of a report to PDF, how to remove my html, and or render to a
> pdf w/out my param controls?
> Can I call a NewWindow? or what should I do?
> I've overcome how to pass a .Net dataset to a SSRS report, smoke & mirrors, it
> is a kluge but I've got it working.
> It wasn't much code just'a diff'rent way o'do'in it...
> Anyway, my pain.
> On my web page when I call w/rs.render my report to html I get my report at
top
> of the page and my one paramerter textbox and cmd button, no problem.
> However, when I render to PDF, .Net Dev opens and I get trash back.
> When I save to disk I get trash, but if I rename and edit in Notepad, strip
out
> everything after the EOF, basically all the html, I get a viable PDF.
>
>

OK to use one stored procedure for inserts and updates?

I have seen a couple examples where the person used ONE stored procedure (call it SaveOrder) was used for both Inserts and Updates. This would be opposed to having a InsertOrder and UpdateOrder. I'm assuming there was some branching code in there to determine whether the record already existed or not.

My question is this: Is this a good practice? It seems like it might save some duplicate coding.

Just looking for some opinions-

Thanks,

Jim

its ok....

if exist...update

else insert

|||Hi,

I would alway prefer a more granular solution rather than a monolithic approach. Otherwise procedure could get (depending on your code) hard to read and debug.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

Thank you both-

Jim

sql

Odd Question

Does anyone know of a way to call an Exell macro in a Sql Server DTS package?
Regards
jimI assume that you saved your package as a Visual Basic File
(Enterprise Manager->Package->Save as: Location->Visual Basic File)
Once having the VB code for the package, you can insert there the appropiate code to run the macro:

mySum = Application.Run("MyCustom.xlm!My_Func_Sum", 1, 5)
MsgBox "Macro result: " & mySum

Of course you'll need to define an Excel object, open it and work with the object properties, but basically that's the idea.

Originally posted by JDionne
Does anyone know of a way to call an Exell macro in a Sql Server DTS package?
Regards
jim|||Originally posted by dbadelphes
I assume that you saved your package as a Visual Basic File
(Enterprise Manager->Package->Save as: Location->Visual Basic File)
Once having the VB code for the package, you can insert there the appropiate code to run the macro:

mySum = Application.Run("MyCustom.xlm!My_Func_Sum", 1, 5)
MsgBox "Macro result: " & mySum

Of course you'll need to define an Excel object, open it and work with the object properties, but basically that's the idea.

hmmm thats a bit more than i understand. is there any documentation on that that i can read?
Jim|||Search for "Saving a DTS Package to a Visual Basic File" in Books Online. It's pretty well documented, then for macros look in MSDN documentation on Microsoft's site (check Q219905 - How to Dynamically Add and Run a VBA Macro from Visual Basic).

Hope it helps.

Originally posted by JDionne
hmmm thats a bit more than i understand. is there any documentation on that that i can read?
Jim

ODBC: Call Failed 3146

Hello,
I have a vb program that connects to odbc to an sqlexpress server. When
i try to write data to the db, i get this message:
Release Error: Script #1 (Ascent Capture Database) [3146 Index Table
(dbo.DIGIDOS): ODBC: de oproep is mislukt.]
"de oproep is mislukt" is dutch for "Call failed"
It is an on/off problem, sometimes it works perfectly, but when i try
for the second time i get the error message again. Also found a
suggestion on the internet to walk through the errors of the
dbengine.error but this gave me nothing more then the shown error.
I am using windows xp and a local SQLexpress 2005 server. I am using
the sql server odbc driver 2000.85.1117.00 or should i been using the
sql native client version 2005.90.1399.00 ?
Can someone explain to me what i must do to correct this problem. ?
Thnx,
Johan
The Netherlands
ODBC call failed can be anything so it's not real fun to
troubleshoot. I think the easiest way though is to turn on
ODBC tracing on the client until you get the error. Having
ODBC tracing on will bog down the client so you want to try
to get the error soon and turn tracing off after that. Once
you hit the error, you can go through the ODBC trace log to
find the specific call that had the error.
You turn on ODBC tracing from the ODBC Data Source
Administrator. Go to the tracing tab and click on Start
Tracing now. Note where the log is going to - you can change
the location if you want. You turn off the tracing from the
same place. Just make sure you turn it back off.
-Sue
On 24 Sep 2006 02:54:21 -0700, "Johan"
<hello_2you@.hotmail.com> wrote:

>Hello,
>I have a vb program that connects to odbc to an sqlexpress server. When
>i try to write data to the db, i get this message:
>Release Error: Script #1 (Ascent Capture Database) [3146 Index Table
>(dbo.DIGIDOS): ODBC: de oproep is mislukt.]
>"de oproep is mislukt" is dutch for "Call failed"
>It is an on/off problem, sometimes it works perfectly, but when i try
>for the second time i get the error message again. Also found a
>suggestion on the internet to walk through the errors of the
>dbengine.error but this gave me nothing more then the shown error.
>I am using windows xp and a local SQLexpress 2005 server. I am using
>the sql server odbc driver 2000.85.1117.00 or should i been using the
>sql native client version 2005.90.1399.00 ?
>Can someone explain to me what i must do to correct this problem. ?
>Thnx,
>Johan
>The Netherlands
|||Thank you very much, the problem is solved. Did not know about the
tracer, but when i used it, it gave me just the info i needed. It
seemed i had a wrong unique index ;)
Fixed it and now everything runs smoothly !
Sue Hoegemeier wrote:[vbcol=seagreen]
> ODBC call failed can be anything so it's not real fun to
> troubleshoot. I think the easiest way though is to turn on
> ODBC tracing on the client until you get the error. Having
> ODBC tracing on will bog down the client so you want to try
> to get the error soon and turn tracing off after that. Once
> you hit the error, you can go through the ODBC trace log to
> find the specific call that had the error.
> You turn on ODBC tracing from the ODBC Data Source
> Administrator. Go to the tracing tab and click on Start
> Tracing now. Note where the log is going to - you can change
> the location if you want. You turn off the tracing from the
> same place. Just make sure you turn it back off.
> -Sue
> On 24 Sep 2006 02:54:21 -0700, "Johan"
> <hello_2you@.hotmail.com> wrote:
|||Glad it's fixed - thanks for posting back!
-Sue
On 25 Sep 2006 01:40:45 -0700, "Johan"
<hello_2you@.hotmail.com> wrote:
[vbcol=seagreen]
>Thank you very much, the problem is solved. Did not know about the
>tracer, but when i used it, it gave me just the info i needed. It
>seemed i had a wrong unique index ;)
>Fixed it and now everything runs smoothly !
>
>Sue Hoegemeier wrote:

ODBC: Call Failed 3146

Hello,
I have a vb program that connects to odbc to an sqlexpress server. When
i try to write data to the db, i get this message:
Release Error: Script #1 (Ascent Capture Database) [3146 Index Table
(dbo.DIGIDOS): ODBC: de oproep is mislukt.]
"de oproep is mislukt" is dutch for "Call failed"
It is an on/off problem, sometimes it works perfectly, but when i try
for the second time i get the error message again. Also found a
suggestion on the internet to walk through the errors of the
dbengine.error but this gave me nothing more then the shown error.
I am using Windows XP and a local SQLexpress 2005 server. I am using
the sql server odbc driver 2000.85.1117.00 or should i been using the
sql native client version 2005.90.1399.00 ?
Can someone explain to me what i must do to correct this problem. ?
Thnx,
Johan
The NetherlandsODBC call failed can be anything so it's not real fun to
troubleshoot. I think the easiest way though is to turn on
ODBC tracing on the client until you get the error. Having
ODBC tracing on will bog down the client so you want to try
to get the error soon and turn tracing off after that. Once
you hit the error, you can go through the ODBC trace log to
find the specific call that had the error.
You turn on ODBC tracing from the ODBC Data Source
Administrator. Go to the tracing tab and click on Start
Tracing now. Note where the log is going to - you can change
the location if you want. You turn off the tracing from the
same place. Just make sure you turn it back off.
-Sue
On 24 Sep 2006 02:54:21 -0700, "Johan"
<hello_2you@.hotmail.com> wrote:

>Hello,
>I have a vb program that connects to odbc to an sqlexpress server. When
>i try to write data to the db, i get this message:
>Release Error: Script #1 (Ascent Capture Database) [3146 Index Table
>(dbo.DIGIDOS): ODBC: de oproep is mislukt.]
>"de oproep is mislukt" is dutch for "Call failed"
>It is an on/off problem, sometimes it works perfectly, but when i try
>for the second time i get the error message again. Also found a
>suggestion on the internet to walk through the errors of the
>dbengine.error but this gave me nothing more then the shown error.
>I am using Windows XP and a local SQLexpress 2005 server. I am using
>the sql server odbc driver 2000.85.1117.00 or should i been using the
>sql native client version 2005.90.1399.00 ?
>Can someone explain to me what i must do to correct this problem. ?
>Thnx,
>Johan
>The Netherlands|||Thank you very much, the problem is solved. Did not know about the
tracer, but when i used it, it gave me just the info i needed. It
seemed i had a wrong unique index ;)
Fixed it and now everything runs smoothly !
Sue Hoegemeier wrote:[vbcol=seagreen]
> ODBC call failed can be anything so it's not real fun to
> troubleshoot. I think the easiest way though is to turn on
> ODBC tracing on the client until you get the error. Having
> ODBC tracing on will bog down the client so you want to try
> to get the error soon and turn tracing off after that. Once
> you hit the error, you can go through the ODBC trace log to
> find the specific call that had the error.
> You turn on ODBC tracing from the ODBC Data Source
> Administrator. Go to the tracing tab and click on Start
> Tracing now. Note where the log is going to - you can change
> the location if you want. You turn off the tracing from the
> same place. Just make sure you turn it back off.
> -Sue
> On 24 Sep 2006 02:54:21 -0700, "Johan"
> <hello_2you@.hotmail.com> wrote:
>|||Glad it's fixed - thanks for posting back!
-Sue
On 25 Sep 2006 01:40:45 -0700, "Johan"
<hello_2you@.hotmail.com> wrote:
[vbcol=seagreen]
>Thank you very much, the problem is solved. Did not know about the
>tracer, but when i used it, it gave me just the info i needed. It
>seemed i had a wrong unique index ;)
>Fixed it and now everything runs smoothly !
>
>Sue Hoegemeier wrote:

ODBC Trusted_Connection call to SQLGetInfo returns DBO as user name, not NT User

Hello, all:
I am connecting to SQL Server 2000 with a trusted connection, and that is working fine. I then am issuing a SQLGetInfo call to find out the SQL_USER_NAME, which is always returning dbo instead of (my) Windows NT login name, which I expect to see. THe authentication is (apparently) confirmed by the SQL Server session monitor where it shows the right Windows NT user name logged in, over ODBC. With a standard SQL Login, untrusted, I definitely get the right user name back, not dbo.

So:

Login Type / user id /returned value from SQLGetInfo

Windows Authentication / Windows login / dbo
SQL Authentication / Windows login (UID) / UID

The problem is that I am trying to confirm that the userid entered in a dialog or passed on the command line to my application matches the actual connected user name inside SQL Server...

My questions:
Is there some pathology in Trusted_Connections that masks the Windows/NT login name and always returns UID 'dbo' from a call to SQLGetInfo? Is there a MSS (public) stored procedure that can robustly give back the logged in user name so I can bypass the SQLGetInfo call?I think I have finally wrestled this beast to the ground. Here's the story, in case anybody is interested:

1) When making an NTLM trusted connection to MSS, logging in using my NT login name e.g. as amarshall, the system was always saying the connected user is dbo, no matter what. This can be verified by using a SQL tool like SQL Query Analyzer, connecting over a trusted connection to MSS, and entering SELECT USER; or SELECT USER_NAME() or any variants. These will always return dbo, which is not the real 'user' of interest, but the schema owner. What we want is to confirm 'amarshall' is a (legitimate) user, meaning, SQL Server knows who this is..

2) So, use the SYSTEM_USER call, and the result is AMARSHALL-CAM\amarshall (Host\user).

3) Then, just perform substring match to see if what the user has typed into the login dialog (amarshall) matches what is in the call result. If so, good user, otherwise, reject (program decides).

4) I do NOT strip off the host name or anything - just substring match result of SYSTEM_USER call to logins userid.

5) Database connectstring for Powerbuilder must include SECURE=1. For ADO/VB/.NET, has to have something like TRUSTED_CONNECTION=yes (PB does this for me)

6) Have not tested this against the SQL Server Desktop Edition. Should be identical, but who knows?

7) If anybody has a superior resolution, or security concerns, please advise, but this suffices for now.|||dbo is a database user. You seem to want the server login information, which is quite different. I'd use suser_sname (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_setu-sus_86xx.asp).

-PatP