In MSSQL Server 2008, how would I go about creating a scheduled process that:
Takes the sum of a float column from specific users in a user column and then comparing which is has the greatest sum and storing that number along with the user whom has that value into a separate table on a weekly basis?
Create a SQL Server scheduled job that executes a stored procedure or raw SQL.
Based on your description, the query could look like this:
insert into table (username, sumofcolumn)
select top 1 username, sum(column)
from table2
group by username
order by sum(column) desc
Personally I prefer to write a service which performs actions periodically, since I have better control of when the actions are to be executed, and everything is in a single place.
If you want to solve your problem with database means only, just create a stored procedure implementing your logic, and call that stored procedure from a scheduled job.
Related
I'm trying to execute a SQL Server stored procedure through Python Pyodbc and to get the selection results printed out into .csv files. But this procedure is currently being used in other daily tasks so I'm worried that if my executing the procedure in python will interrupt the daily scheduled job process in SQL Server Agent. In the procedure, it creates several temporary tables #temp_a, #temp_b, and #temp_c. I'm wondering if these temp tables will break the scheduled jobs that include this procedure since there might be other procedures that will be creating temp table names using the same name such as #temp_a or #temp_b. The temp tables are created inside the procedure but with no delete query written. I could have tested this myself but the database I'm working on right now is just so fragile that I was told not to create tests. Thanks!
Yes
The temp-Tables will be created per Session.
I got the procedure execute by different Sessions on the same time there will be the same count of the temp-tables as sessions executed.
This temp-tables have each a different name:
#V_...._000000003EB1
#V_...._000000003EB8
The example above are the temp-Tables created by the same Procedure executed two times by different sessions at the same time.
So your scenario couldn't happen
Is there a way to find out the number of times a stored procedure is called in last few days in Oracle? Thanks
Checking the past executions can be tricky. But in case if you wish to setup some kind of monitoring for your execution. You can always do that using audit execute by access
audit execute on <schema_name>.<procedure_name> by access;
Post this, you can keep monitoring the procedure execution using dba_audit_trail view;
SELECT os_username, username, obj_name, owner
FROM dba_audit_trail
WHERE obj_name = '<procedure_name>';
I'm currently working with SQL Server 2008 R2, and I have only READ access to a few tables that house production data.
I'm finding that in many cases, it would be extremely nice if I could run something like the following, and get the total record count back that was affected :
USE DB
GO
BEGIN TRANSACTION
UPDATE Person
SET pType = 'retailer'
WHERE pTrackId = 20
AND pWebId LIKE 'rtlr%';
ROLLBACK TRANSACTION
However, seeing as I don't have the UPDATE permission, I cannot successfully run this script without getting :
Msg 229, Level 14, State 5, Line 5
The UPDATE permission was denied on the object 'Person', database 'DB', schema 'dbo'.
My questions :
Is there any way that my account in SQL Server can be configured so that if I want to run an UPDATE script, it would automatically be wrapped in a transaction with an rollback (so no data is actually affected)
I know I could make a copy of that data and run my script against a local SSMS instance, but I'm wondering if there is a permission-based way of accomplishing this.
I don't think there is a way to bypass SQL Server permissions. And I don't think it's a good idea to develop on production database anyway. It would be much better to have development version of the database you work with.
If the number of affected rows is all you need then you can run select instead of update.
For example:
select count(*)
from Person
where pTrackId = 20
AND pWebId LIKE 'rtlr%';
If you are only after the amount of rows that would be affected with this update, that would be same amount of rows that currently comply to the WHERE clause.
So you can just run a SELECT statement as such:
SELECT COUNT(pType)
FROM Person WHERE pTrackId = 20
AND pWebId LIKE 'rtlr%';
And you'd get the resulting potential rows affected.
1.First Login as admin in sqlserver
2.Goto login->your name->Check the roles.
3.IF u have write access,then you can accomplish the above task.
4.If not make sure you grant access to write.
If it's strictly necessary to try the update, you could write a stored procedure, accepting dynamic SQL as a string (Your UPDATE query) and wrapping the dynamic SQL in a transaction context which is then rolled back. Your account could then be granted access to that stored procedure.
Personally, I think that's a terrible idea, and incredibly unsafe - some queries break out of such transaction contexts (e.g. ALTER TABLE). You may be able to block those somehow, but it would still be a security/auditing problem.
I recommend writing a query to count the relevant rows:
SELECT COUNT(*)
FROM --tables
WHERE --your where clause
-- any other clauses here e.g. GROUP BY, HAVING ...
I have little to no experience with TSQL and SQL Server - so in MySQL when I want to execute a statement I simply write:
Select * from users
...and then hit ENTER.
However now I see many SQL Server tutorials that you have the GO word immediately after each statement. Do I have to write this? For example:
Select * from users; GO
Or I can simply write:
Select * from users; <enter key pressed...>
In SQL Server, go separates query batches. It's optional in most situations.
In earlier versions of SQL Server, you had to do a go after altering a table, like:
alter table MyTable add MyColumn int
go
select MyColumn from MyTable
If you didn't, SQL Server would parse the query batch, and complain that MyColumn didn't exist. See MSDN:
SQL Server utilities interpret GO as a
signal that they should send the
current batch of Transact-SQL
statements to an instance of SQL
Server. The current batch of
statements is composed of all
statements entered since the last GO,
or since the start of the ad hoc
session or script if this is the first
GO.
GO separates batches, as Andomar wrote.
Some SQL statements (e.g. CREATE SCHEMA) need to be the first or only statements within a batch. For example, MSDN states
The CREATE PROCEDURE statement cannot
be combined with other Transact-SQL
statements in a single batch.
Local variables are also limited to a batch, and therefore are not accessible after a GO.
Go is optional, no need to write that in your sql statements.
You don't have to. What the GO will do is execute each statement (at least in Sql Server)
As the other answerers said before me, you don't really NEED Go.
There is only one case when you have to use it, and that's when you want to create a table or view and then select from it.
For example:
create view MyView as select * from MyTable
go
select * from MyView
Without Go, Sql Server won't execute this because the select statement is not valid, because the view doesn't exist at that moment.
I have two stored procedures I wish to use in my stored procedure, but once I do that it fails to load with the error: "Invalid Argument provided, no rowset retrieved." If I remove either one of them it starts working again.
I have the crystal report set up something like this:
Report:
Group By Tenant.ReferedBy
stored proc here that calculates the tenant's balance
and the second stored proc is in the Select for the report. I only want to select tenant's by a status flag, and I'm getting the status flag from a stored proc.
Neither of the two procedures are linked together in anyway. One returns one value (the one in the select), the other returns multiple (the one in the group by). Neither take any parameters and are both just simple SQL statements stored on the database.
First Proc: GetAllTenantBalances
SELECT (SUM(tblTransaction.AmountPaid) - SUM(tblTransaction.AmountCharged)) AS TenantBalance, tblTransaction.TenantID
FROM tblTransaction
GROUP BY tblTransaction.TenantID
Second Proc: [GetTenantStatusID_Current]
SELECT ID FROM tblTenantStatus WHERE Description = 'Current'
Can anyone tell me why I can't do this, and how to get around it?
You could change the first sp to only sum 'Current' tenants. Or, if you must keep two sp you will have to go to the database expert and join them by the tenant_id.
You could also use sub-reports to give you the data you want. Use on SP on the main, and then another SP on a sub-report.
-JFV
Unless something has changed, you can't call multiple procs from a report. I doubt you can call multiple select statements. You will either need to create one proc that returns both pieces of data or create a subreport for the second proc.