Showing posts with label specific. Show all posts
Showing posts with label specific. Show all posts

Wednesday, March 28, 2012

Long response time at a certain time each week

Our server is experiencing random slowdowns (for specific
inserts, updates or selects) at a certain time each week.
I've checked to make sure something else is not running
and do not see any scheduled jobs during this time. I've
captured a trace file and don't see any reason why it
would take a long time. It is not a busy time on the
server, either.
Any suggestions for some obvious things I could check?
Our environment is SQL Server 2000 with Service Pack 3 on
Windows 2000 with Service Pack 3.
TIA,
Jeanne UngerIs your database configured for auto-shrink? Is there some other activity on
your network that could be causing a slow down?
Jim
"Jeanne Unger" <anonymous@.discussions.microsoft.com> wrote in message
news:0a9601c3fb02$5f1bf540$a101280a@.phx.gbl...
> Our server is experiencing random slowdowns (for specific
> inserts, updates or selects) at a certain time each week.
> I've checked to make sure something else is not running
> and do not see any scheduled jobs during this time. I've
> captured a trace file and don't see any reason why it
> would take a long time. It is not a busy time on the
> server, either.
> Any suggestions for some obvious things I could check?
> Our environment is SQL Server 2000 with Service Pack 3 on
> Windows 2000 with Service Pack 3.
> TIA,
> Jeanne Unger|||It was configured to auto shrink, so I turned that off
yesterday. I will find out Sunday night whether or not it
made a difference.
I haven't been able to find anything on the network that
is causing the slowdown, and it is specific to this
particular database. For example, the queries usually
take 0-16 milliseconds but at 00:30 GMT it can take 3-4
minutes. No other applications that run across the
network are affected.
>--Original Message--
>Is your database configured for auto-shrink? Is there
some other activity on
>your network that could be causing a slow down?
>Jim
>"Jeanne Unger" <anonymous@.discussions.microsoft.com>
wrote in message
>news:0a9601c3fb02$5f1bf540$a101280a@.phx.gbl...
>> Our server is experiencing random slowdowns (for
specific
>> inserts, updates or selects) at a certain time each
week.
>> I've checked to make sure something else is not running
>> and do not see any scheduled jobs during this time.
I've
>> captured a trace file and don't see any reason why it
>> would take a long time. It is not a busy time on the
>> server, either.
>> Any suggestions for some obvious things I could check?
>> Our environment is SQL Server 2000 with Service Pack 3
on
>> Windows 2000 with Service Pack 3.
>> TIA,
>> Jeanne Unger
>
>.
>

Monday, March 12, 2012

Logn error

I'm having a bizarre error occur with one specific user. For starters, I hav
e
an SQL back-end with an Access data project front end. All of my users are
members of a SQLUSERS group, with the correct permissions.
When one specific user, Zack, logs into the db, he does so under the
SQLUSERS group. Everything runs smoothly until Zack tries to perform a
particular action that imports data from a fixed-width text file on CD. When
he does this, the system adds Zack as a separate user, even though he's
already part of the SQLUSERS group. The new Zack user inherits the
permissions from SQLUSERS, and during the data import process the system
creates new tables for Zack. Some fields don't have the correct data types,
which causes an error. Zack becomes the owner of these new import tables.
When any other member of SQLUSERS performs the same action, the system
deletes the data from, and reuses the existing tables.
Has anyone encountered anything similar to this?Hi
SQL Server will not create new users on it's own, therefore you have some
code that will be doing this. If your code is creating new (staging) tables
then zack will own them if he is not the dbo or a sysadmin. If the tables do
not already exist I would expect the same behaviour for other users that hav
e
the same privileges for Zack unless your code is conditional on who is
running it. If permissions are granted to the SQLUsers group other users may
be able to access and truncate the tables. For these users the code must kno
w
that Zack is the owner and referencing them using it.
You should review the code and/or use profiler to see what statements are
being sent to the database.
John
"mike" wrote:

> I'm having a bizarre error occur with one specific user. For starters, I h
ave
> an SQL back-end with an Access data project front end. All of my users are
> members of a SQLUSERS group, with the correct permissions.
> When one specific user, Zack, logs into the db, he does so under the
> SQLUSERS group. Everything runs smoothly until Zack tries to perform a
> particular action that imports data from a fixed-width text file on CD. Wh
en
> he does this, the system adds Zack as a separate user, even though he's
> already part of the SQLUSERS group. The new Zack user inherits the
> permissions from SQLUSERS, and during the data import process the system
> creates new tables for Zack. Some fields don't have the correct data types
,
> which causes an error. Zack becomes the owner of these new import tables.
> When any other member of SQLUSERS performs the same action, the system
> deletes the data from, and reuses the existing tables.
> Has anyone encountered anything similar to this?

Wednesday, March 7, 2012

Login Times

Yes there is.
Have a couple of jobs running.
Start the job at a specific time
In the first job put in EXEC sp_denylogin '<usr_name>'
Then if you need to kill any of the processes for that
user still in there.
in the second login put EXEC sp_grantlogin '<usr_name>'.
So you start the first job at say 7pm
And the second job at say 8.30am
Peter
"I may be drunk, Miss, but in the morning I will be sober
and you will still be ugly."
Winston Churchill

>--Original Message--
>Helo,
>Is there any way I could grant or deny a user login based
on the time of
>day?
>I'm running mad with this issue, since not everybody is a
full time
>employee, and for security reasons I would want to block
their logins when
>they are supposed to be out of the office.
>Thanks in advance.
>
>.
>Thanks!
I wasn't thinking about jobs at all... I was running mad trying to pull in
triggers, and even thinking about changing the network configuration... but
my head wasn't thinking on jobs at all and it's a really nice answer.
Thank you Peter.
"Peter The Spate" <anonymous@.discussions.microsoft.com> escribi en el
mensaje news:19dd01c4bb6a$f99c8b10$a301280a@.phx.gbl...[vbcol=seagreen]
> Yes there is.
> Have a couple of jobs running.
> Start the job at a specific time
> In the first job put in EXEC sp_denylogin '<usr_name>'
> Then if you need to kill any of the processes for that
> user still in there.
> in the second login put EXEC sp_grantlogin '<usr_name>'.
> So you start the first job at say 7pm
> And the second job at say 8.30am
> Peter
> "I may be drunk, Miss, but in the morning I will be sober
> and you will still be ugly."
> Winston Churchill
>
> on the time of
> full time
> their logins when