losing permisions in tempdb

Hi,
I have noticed that everytime sql server restarts the permission on tempdb g
o away. Is there a way to fix this?
Also i thought this sort of information was stored in the master database?Tempdb is recreated whenever SQL Server is restarted. Guest
user exists in tempdb by default which is how users access
tempdb for temp tables and such. What permissions are
causing problems? Tempdb is recreated using the model
database as a template and maybe you have something wrong
with the model database. Hard to say as I don't know what
you are trying to accomplish or what problems the recreation
of tempdb is causing you.
-Sue
On Thu, 1 Apr 2004 08:11:16 -0800, "Jason"
<anonymous@.discussions.microsoft.com> wrote:

>Hi,
>I have noticed that everytime sql server restarts the permission on tempdb
go away. Is there a way to fix this?
>Also i thought this sort of information was stored in the master database?|||Generally you shouldn't be granting permissions to users in tempdb. What is
the requirement for this? (As Sue said, tempdb gets rebuilt every time the
SQL Instance or server is restarted - this is a desirable thing).|||Hi,
It is a vendor supplied solution. They use tempdb to store session state.
They didn't use a guest account to access tempdb though, there is an applica
tion account that reads and writes to tempdb with session state data.
When the server is bounced, SQL Server restarts and the application account
loses all privledges to the temp db.
Also, I thought all the privledge info was saved in the master db, it seems
based on this that at least some info is also stored in the target database
as well...can you explain, or point me to a book online chapter that explai
ns this.
thanks|||Try setting up whatever users, permissions the application
needs in model database. Tempdb is recreated using model as
a template.
The help topic Users in SQL Server books online explains the
difference between users and logins and some of what is
stored where. User accounts are specific to a database and
the user account is associated with permissions and object
ownership in a given database. Master will store information
on logins as well as user information specific to the master
database (not all of the databases).
-Sue
On Mon, 5 Apr 2004 06:16:06 -0700, jason_fin
<anonymous@.discussions.microsoft.com> wrote:

>Hi,
>It is a vendor supplied solution. They use tempdb to store session state.
They didn't use a guest account to access tempdb though, there is an applic
ation account that reads and writes to tempdb with session state data.
>When the server is bounced, SQL Server restarts and the application account
loses all privledges to the temp db.
>Also, I thought all the privledge info was saved in the master db, it seems
based on this that at least some info is also stored in the target database
as well...can you explain, or point me to a book online chapter that expla
ins this.
>thanks
>

Looking for options to fix a poorly implemented solution

So, I've started a new job recently where I am doing work on a SQL
Server database designed by a third party software company, which also
wrote the client software accompanying the database. The client
software is crap, the data model sucks rocks, and I'm stuck with it.
So in no way can I modify client code, or redesign any element of
relational model. I've been able to modify stored procedures and
triggers for performance, perform regular maintenance tasks, and
upgrade all upgradable elements, but that's about it. On top of that,
people developed an internal method of using the datbase that is
causing it to grow way too fast. Basically, there is one table with a
BLOB field that people are using to store Word documents containing
scanned images (part of their efforts to go to a paperless system).
Documents are scanned only when there is no other way to get the
information into the system (client signatures, legal documents from
courts, etc). And I've been charged with getting the size of the
database down. Yay.
Brainstorming for solutions, I was wondering if there is any possible
way to compress BLOB fields in a way that is completely transparent to
the client. I can't think of a way, so I have little hope for that
idea. Another is to go in and make sure all of the images are
compressed. That will only yield marginal results. Finally, going in
and replacing all of the scanned documents with documents that point
to a UNC path with all of the extracted documents is a solution that
will required quite a bit of work, but is possible. (If it were up to
me, I'd just say to heck with it and keep some documents in a paper
system). Any thought about what I could do?
Thanks!When I was at Sprint, the Place Where Consultants Go To Be Punished, our
department got into a document archiving frenzy. Ended up storing all
documents into PDFs, storing them on the server, with only a link to the
document in the database.
- Wm
"AAAWalrus" <aaawalrus@.yahoo.com> wrote in message
news:8b266bc2.0312101204.32a99d74@.posting.google.com...
> So, I've started a new job recently where I am doing work on a SQL
> Server database designed by a third party software company, which also
> wrote the client software accompanying the database. The client
> software is crap, the data model sucks rocks, and I'm stuck with it.
> So in no way can I modify client code, or redesign any element of
> relational model. I've been able to modify stored procedures and
> triggers for performance, perform regular maintenance tasks, and
> upgrade all upgradable elements, but that's about it. On top of that,
> people developed an internal method of using the datbase that is
> causing it to grow way too fast. Basically, there is one table with a
> BLOB field that people are using to store Word documents containing
> scanned images (part of their efforts to go to a paperless system).
> Documents are scanned only when there is no other way to get the
> information into the system (client signatures, legal documents from
> courts, etc). And I've been charged with getting the size of the
> database down. Yay.
> Brainstorming for solutions, I was wondering if there is any possible
> way to compress BLOB fields in a way that is completely transparent to
> the client. I can't think of a way, so I have little hope for that
> idea. Another is to go in and make sure all of the images are
> compressed. That will only yield marginal results. Finally, going in
> and replacing all of the scanned documents with documents that point
> to a UNC path with all of the extracted documents is a solution that
> will required quite a bit of work, but is possible. (If it were up to
> me, I'd just say to heck with it and keep some documents in a paper
> system). Any thought about what I could do?
> Thanks!