Showing posts with label determine. Show all posts
Showing posts with label determine. Show all posts

Monday, March 26, 2012

External scheduler for reports

Hi, here is my problem:
Because of some usability terms, I need to use SSRS scheduler to determine reports creation frequency (minimum frequency is once a day)I need to use an external scheduler to SSRS in order to launch reports creation daily, after some other batch tasks execution that must be completed before launching report creation.
And I have no idea on how to do that properly. Can somebody help me?

Thanks!

Hi,

Reporting Services has scheduling functionality included by default. You can use both report based schedules as global schedules to update your reports.

To use schedules, you must make sure that your reports are using fixed credentials to connect to the database (so no integrated security).

You can set up the schedules via the report manager.

Greetz,

Geert

Geert Verhoeven
Consultant @. Ausy Belgium

My Personal Blog

|||Thanks for the answer.

I think I expressed myself in a bad way.
Creating my reports needs some batch tasks to be completed. These batch tasks are planed by a company scheduler.
So, my problem is that I want to be able to change report creation time (e.g. from 2am to 3 or 4am) with this company scheduler to ensure that all batch tasks had been totally completed before report creation starts.|||

Hi,

You can also create a .NET executable that creates the snapshot and then call the executable after the batch has been finished. This way you are sure that the batches are finished.

Greetz,

Geert

Geert Verhoeven
Consultant @. Ausy Belgium

My Personal Blog

Friday, March 23, 2012

Extent of FullText Population

Is there a means to determine to what extent an existing
SQL table has been populated with the FullText indexing
service .... so to try to assess how long an
incremental population may take ?
Thanks
PhilipPhilip,
Yes, you can use one or more the system metadata, such as
FullTextCatalogProperty('<FT_Catalog_Name>', 'populatestatus') to monitor FT
Populations.
Note, you can also post FTS related questions to the newsgroup:
microsoft.public.sqlserver.fulltext
Regards,
John
"Philip" <plippard@.nc.rr.com> wrote in message
news:02b301c34f27$15108970$a301280a@.phx.gbl...
> Is there a means to determine to what extent an existing
> SQL table has been populated with the FullText indexing
> service .... so to try to assess how long an
> incremental population may take ?
> Thanks
> Philip

Wednesday, March 21, 2012

Extended stored procedure xp_cmdshell

Hello,

I have a question regarding the extended SPC 'xp_cmdshell'.

Basically I want to determine the username and userdomain in a stored procedure and what I know is that you can get this information in a "DOS-Box" with 'Set username' or 'Set userdomain'.

But if I use the above mentioned extended stored procedure in the following way:

exec master..xp_cmdshell 'set username'
I don´t get any resultset.

Does anyone know why I get different results depending on the fact if I call the 'set'-command in a "DOS-Box" or with the appropriate stored procedure?

Thank you for any help>>Basically I want to determine the username and userdomain in a stored procedure and what I know is that you can get this information in a "DOS-Box" with 'Set username' or 'Set userdomain'.

You are aware that xp_xmdshell is running in the context of Sql Server. So you will only ever see information pertaining tho the server - not any client.

What user and domain are you trying to retrieve? The client connecting to SQL Server or the Server itself?|||Hello,

yes, you are absolutely right! I am aware of this but I have just tried this on my local machine. I have installed SQL-server local and I was just wondering because of this differences on the same machine. I know that I can´t use this in a production environment because of the fact that this SPC is running in the context of the server and does not affect any client.

What I basically want is to retrieve the domainname and -user of the client connection with a stored procedure.

Do you know a practicable method to do this?

Thanks,|||SQL Server provides several functions for this purpose each with differing behavior. Have a look in SQL Server Books Online at the following keywords for starters:

USER_NAME()
SESSION_USER
USER|||Hello,

thank you for the advice to the functions of sql server. I have looked around now for a while and have found a function which returns indeed the domainname and domainusername of the connected client.
Just beside -- the functions you mentioned just give back the actually sql-server user in the selected database which is in my environment always 'dbo'.

You can get the domaininfo with the following piece of code:DECLARE @.System_User char(30)
SET @.System_User=SYSTEM_USER
PRINT @.System_User
Regards,

Monday, March 19, 2012

Extended SP Questions

I would like to know if I can determine the calling user from within
an extended stored procedure. I assume it's accessible in the
SRV_PROC structure somewhere.

Also, does anyone know of a comprehensive list of what is included in
the SRV_PROC structure?

This is for SQL Server 2000.

Thanks"Bruce" wrote:
> I would like to know if I can determine the calling user from within
> an extended stored procedure. I assume it's accessible in the
> SRV_PROC structure somewhere.
> Also, does anyone know of a comprehensive list of what is included in
> the SRV_PROC structure?
> This is for SQL Server 2000.
> Thanks

My understanding is that SRV_PROC is intended to be an opaque structure and
as such you shouldn't hack it for production purposes (I mean, running my
own C/C++ in the process space of a production SQL Server gives me the
heebie-geebies anyway).

That being said, what about srv_pfield? It seems to provide quite a bit of
information...

Craig

Extended SP Questions

I would like to know if I can determine the calling user from within
an extended stored procedure. I assume it's accessible in the
SRV_PROC structure somewhere.

Also, does anyone know of a comprehensive list of what is included in
the SRV_PROC structure?

This is for SQL Server 2000.

Thanks"Bruce" wrote:
> I would like to know if I can determine the calling user from within
> an extended stored procedure. I assume it's accessible in the
> SRV_PROC structure somewhere.
> Also, does anyone know of a comprehensive list of what is included in
> the SRV_PROC structure?
> This is for SQL Server 2000.
> Thanks

My understanding is that SRV_PROC is intended to be an opaque structure and
as such you shouldn't hack it for production purposes (I mean, running my
own C/C++ in the process space of a production SQL Server gives me the
heebie-geebies anyway).

That being said, what about srv_pfield? It seems to provide quite a bit of
information...

Craig|||Thanks, srv_pfield worked great.