Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Tuesday, March 20, 2012

Referencing another table in MS_SQL?

Hello everyone,
We would like to have the user_ID field in the security table reference the
email field in the Cusomer table. Basically, I would like instant updates
of security login information when the email is changed/added in the
customer table. I would prefer not to have periodic updates/sync. The
preferred method would reference the email field rather than update from the
email field.
Example of use: When an end user modifies their personal info (email field
in the customer table), the login will instantly be set/updated in the
user_ID field in the security table.
Any help is appreciated. Thanks."Kevin" <kevin_aoki@.NOSPAMhotmail.com123> wrote in message
news:9Oyhd.80$2N2.46980@.news.uswest.net...
> Hello everyone,
> We would like to have the user_ID field in the security table reference
the
> email field in the Cusomer table. Basically, I would like instant updates
> of security login information when the email is changed/added in the
> customer table. I would prefer not to have periodic updates/sync. The
> preferred method would reference the email field rather than update from
the
> email field.
> Example of use: When an end user modifies their personal info (email field
> in the customer table), the login will instantly be set/updated in the
> user_ID field in the security table.
> Any help is appreciated. Thanks.
Are the columns compatible datatypes? If so make the user_id column in the
security table a foreign key referencing the email column in the customer
table WITH UPDATE CASCADE. In order for this to work rhw email column must
have a UNIQUE or PRIMARY KEY CONSTRAINT.
http://snodland.blogspot.com
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 30/10/2004|||"Kevin" <kevin_aoki@.NOSPAMhotmail.com123> wrote in message
news:9Oyhd.80$2N2.46980@.news.uswest.net...
> Hello everyone,
> We would like to have the user_ID field in the security table reference
> the
> email field in the Cusomer table. Basically, I would like instant updates
> of security login information when the email is changed/added in the
> customer table. I would prefer not to have periodic updates/sync. The
> preferred method would reference the email field rather than update from
> the
> email field.
> Example of use: When an end user modifies their personal info (email field
> in the customer table), the login will instantly be set/updated in the
> user_ID field in the security table.
> Any help is appreciated. Thanks.
Two words: UPDATE TRIGGER

Referencing another table in MS_SQL?

Hello everyone,
We would like to have the user_ID field in the security table reference the
email field in the Cusomer table. Basically, I would like instant updates
of security login information when the email is changed/added in the
customer table. I would prefer not to have periodic updates/sync. The
preferred method would reference the email field rather than update from the
email field.
Example of use: When an end user modifies their personal info (email field
in the customer table), the login will instantly be set/updated in the
user_ID field in the security table.
Any help is appreciated. Thanks."Kevin" <kevin_aoki@.NOSPAMhotmail.com123> wrote in message
news:9Oyhd.80$2N2.46980@.news.uswest.net...
> Hello everyone,
> We would like to have the user_ID field in the security table reference
the
> email field in the Cusomer table. Basically, I would like instant updates
> of security login information when the email is changed/added in the
> customer table. I would prefer not to have periodic updates/sync. The
> preferred method would reference the email field rather than update from
the
> email field.
> Example of use: When an end user modifies their personal info (email field
> in the customer table), the login will instantly be set/updated in the
> user_ID field in the security table.
> Any help is appreciated. Thanks.
Are the columns compatible datatypes? If so make the user_id column in the
security table a foreign key referencing the email column in the customer
table WITH UPDATE CASCADE. In order for this to work rhw email column must
have a UNIQUE or PRIMARY KEY CONSTRAINT.
http://snodland.blogspot.com
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 30/10/2004|||"Kevin" <kevin_aoki@.NOSPAMhotmail.com123> wrote in message
news:9Oyhd.80$2N2.46980@.news.uswest.net...
> Hello everyone,
> We would like to have the user_ID field in the security table reference
> the
> email field in the Cusomer table. Basically, I would like instant updates
> of security login information when the email is changed/added in the
> customer table. I would prefer not to have periodic updates/sync. The
> preferred method would reference the email field rather than update from
> the
> email field.
> Example of use: When an end user modifies their personal info (email field
> in the customer table), the login will instantly be set/updated in the
> user_ID field in the security table.
> Any help is appreciated. Thanks.
Two words: UPDATE TRIGGER

Referencing another table in MS_SQL?

Hello everyone,
We would like to have the user_ID field in the security table reference the
email field in the Cusomer table. Basically, I would like instant updates
of security login information when the email is changed/added in the
customer table. I would prefer not to have periodic updates/sync. The
preferred method would reference the email field rather than update from the
email field.
Example of use: When an end user modifies their personal info (email field
in the customer table), the login will instantly be set/updated in the
user_ID field in the security table.
Any help is appreciated. Thanks.
"Kevin" <kevin_aoki@.NOSPAMhotmail.com123> wrote in message
news:9Oyhd.80$2N2.46980@.news.uswest.net...
> Hello everyone,
> We would like to have the user_ID field in the security table reference
the
> email field in the Cusomer table. Basically, I would like instant updates
> of security login information when the email is changed/added in the
> customer table. I would prefer not to have periodic updates/sync. The
> preferred method would reference the email field rather than update from
the
> email field.
> Example of use: When an end user modifies their personal info (email field
> in the customer table), the login will instantly be set/updated in the
> user_ID field in the security table.
> Any help is appreciated. Thanks.
Are the columns compatible datatypes? If so make the user_id column in the
security table a foreign key referencing the email column in the customer
table WITH UPDATE CASCADE. In order for this to work rhw email column must
have a UNIQUE or PRIMARY KEY CONSTRAINT.
http://snodland.blogspot.com
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 30/10/2004
|||"Kevin" <kevin_aoki@.NOSPAMhotmail.com123> wrote in message
news:9Oyhd.80$2N2.46980@.news.uswest.net...
> Hello everyone,
> We would like to have the user_ID field in the security table reference
> the
> email field in the Cusomer table. Basically, I would like instant updates
> of security login information when the email is changed/added in the
> customer table. I would prefer not to have periodic updates/sync. The
> preferred method would reference the email field rather than update from
> the
> email field.
> Example of use: When an end user modifies their personal info (email field
> in the customer table), the login will instantly be set/updated in the
> user_ID field in the security table.
> Any help is appreciated. Thanks.
Two words: UPDATE TRIGGER

Friday, March 9, 2012

Reference for Security Nazis

Does anyone know of a quick reference I could provide to the it security
folks at my work that outlines what file extensions, ports, and dll's sql
server uses? They've gone hog wild with 'security' software here to the
point that they invariably end up shutting down one behavior or another
within SQL each time they do a 'security upgrade'. Grrrr.

TWSince no one replied, and for the sake of the group, I'll post what I've
come up *so far* as far as necessary ports, file extensions, etc that SQL
needs ...

PORTS:
1433

PROTOCOLS:
smtp

FILE EXTENSIONS:
..mdf
..ldf
..bak
..sql
..csv
..rpt

...I'll update as I come up with more

--TW

"Tech Witch" <tech.witch@.gmail.NOSPAM.com> wrote in message
news:Q_Yzd.6775$iC4.5546@.newssvr30.news.prodigy.co m...
> Does anyone know of a quick reference I could provide to the it security
> folks at my work that outlines what file extensions, ports, and dll's sql
> server uses? They've gone hog wild with 'security' software here to the
> point that they invariably end up shutting down one behavior or another
> within SQL each time they do a 'security upgrade'. Grrrr.
> TW|||Hi

In some ways your security guys should be telling you what they want to do
and what effect it should have. You should change from the standard ports,
SMTP is not needed as a default. Not sure why file extensions are needed,
you should avoid virus checking the database files, None of the extension
you mention contain executable code, restricted access to programs and
directories should be implemented, and non-essential ones removed.

The is alot of information on http://www.sqlsecurity.com
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=22
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=24

http://www.microsoft.com/security/g.../SQLServer.mspx
http://www.microsoft.com/technet/pr...n/sp3sec04.mspx
http://www.microsoft.com/technet/se...s/mbsahome.mspx
http://www.microsoft.com/downloads/...&displaylang=en

You should be working with the security guys, they may have already saved
your skin.

John

"Tech Witch" <tech.witch@.gmail.NOSPAM.com> wrote in message
news:SkCAd.4116$F67.400@.newssvr12.news.prodigy.com ...
> Since no one replied, and for the sake of the group, I'll post what I've
> come up *so far* as far as necessary ports, file extensions, etc that SQL
> needs ...
> PORTS:
> 1433
> PROTOCOLS:
> smtp
> FILE EXTENSIONS:
> .mdf
> .ldf
> .bak
> .sql
> .csv
> .rpt
> ...I'll update as I come up with more
> --TW
> "Tech Witch" <tech.witch@.gmail.NOSPAM.com> wrote in message
> news:Q_Yzd.6775$iC4.5546@.newssvr30.news.prodigy.co m...
>> Does anyone know of a quick reference I could provide to the it security
>> folks at my work that outlines what file extensions, ports, and dll's sql
>> server uses? They've gone hog wild with 'security' software here to the
>> point that they invariably end up shutting down one behavior or another
>> within SQL each time they do a 'security upgrade'. Grrrr.
>>
>> TW
>>
>>|||Thanks, John. I will check these links out. To give you a better idea of
what I'm up against, we had several incidents where our security folks
applied a series of patches that caused some undesirable effects like using
a resource-intensive application to perform virus scanning on files with
..BAK, .MDF, and .LDF extensions each time the files were written (some were
in the GIGs), then they disabled our SMTP ports on the servers with some
firewall software, causing our SQL alerts to stop being sent to DBA's (we
don't use SQL mail here). I'm getting tired of them not telling us what
they are changing and not testing the results of said actions, so I want to
come up with a list of necessary SQL functions & files for them to refer to
next time. Thanks again for your suggestions. I'll post an updated list
when I'm done.

TW

"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:41d3238e$0$5263$afc38c87@.news.easynet.co.uk.. .
> In some ways your security guys should be telling you what they want to do
> and what effect it should have. You should change from the standard ports,
> SMTP is not needed as a default. Not sure why file extensions are needed,
> you should avoid virus checking the database files, None of the extension
> you mention contain executable code, restricted access to programs and
> directories should be implemented, and non-essential ones removed.
> <snip>
> You should be working with the security guys, they may have already saved
> your skin.