From tuxedo_man at hotmail.com Wed May 4 01:47:50 2005 From: tuxedo_man at hotmail.com (Billy Pang) Date: Wed, 04 May 2005 06:47:50 +0000 Subject: [dba-SQLServer] outer joins? Message-ID: Hello: Can I ask for the group's opinion about something? Is there any performance differences between an INNER JOIN and an OUTER JOIN query? I know the two joins may or may not produce the same resultset (depending on data) but I am curious if anyone has come across any difference in terms of performance, generally speaking of course. Should OUTER JOINs be avoided in general unless absolutely necessary? Thanks Billy From fhtapia at gmail.com Wed May 4 01:56:08 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 3 May 2005 23:56:08 -0700 Subject: [dba-SQLServer] outer joins? In-Reply-To: References: Message-ID: OTTOMH I can't think of an instance for needing an outer join unless it's for the request of the data, (likewise an inner join). As far as performance you're going to on the avg return more rows in an OUTER JOIN (right?), thus more time, On 5/3/05, Billy Pang wrote: > > Hello: > > Can I ask for the group's opinion about something? Is there any > performance > differences between an INNER JOIN and an OUTER JOIN query? I know the two > joins may or may not produce the same resultset (depending on data) but I > am > curious if anyone has come across any difference in terms of performance, > generally speaking of course. Should OUTER JOINs be avoided in general > unless absolutely necessary? > > Thanks > > Billy > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From cfoust at infostatsystems.com Wed May 4 10:26:31 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 4 May 2005 08:26:31 -0700 Subject: [dba-SQLServer] outer joins? Message-ID: My experience, admittedly subjective, is that outer joins are FASTER than inner joins, perhaps because an outer join only evaluates one table to find matches rather than having to walk the indexes in both tables. Charlotte Foust -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: Tuesday, May 03, 2005 11:56 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] outer joins? OTTOMH I can't think of an instance for needing an outer join unless it's for the request of the data, (likewise an inner join). As far as performance you're going to on the avg return more rows in an OUTER JOIN (right?), thus more time, On 5/3/05, Billy Pang wrote: > > Hello: > > Can I ask for the group's opinion about something? Is there any > performance > differences between an INNER JOIN and an OUTER JOIN query? I know the two > joins may or may not produce the same resultset (depending on data) but I > am > curious if anyone has come across any difference in terms of performance, > generally speaking of course. Should OUTER JOINs be avoided in general > unless absolutely necessary? > > Thanks > > Billy > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed May 4 10:42:29 2005 From: jwcolby at colbyconsulting.com (John W. Colby) Date: Wed, 04 May 2005 11:42:29 -0400 Subject: [dba-SQLServer] outer joins? In-Reply-To: Message-ID: <000201c550bf$e57590b0$6c7aa8c0@ColbyM6805> Inner and outer joins simply perform different functions in the overall scheme of things so you can't really say "avoid them if possible". An inner join says "only give me records where there is data in both tables". This is used to enforce rules (for example) - if there is no invoice for this client, don't return a record in the invoice report - stuff like that. Outer joins are precisely to allow breaking such rules, allow me to see all clients, WITH ANY INVOICES... But also show clients where there is no invoice. Which you use depends entirely on your purpose with the query. You may be able to use an outer join to only display records where there is data in both tables, but that would require jumping through many hoops I'm guessing. And AFAIK you simply cannot use an inner join to display data where there is no data in the related table. They are just different animals used for different things. In my mind your question doesn't make sense. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy Pang Sent: Wednesday, May 04, 2005 2:48 AM To: dba-SQLServer at databaseadvisors.com Subject: [dba-SQLServer] outer joins? Hello: Can I ask for the group's opinion about something? Is there any performance differences between an INNER JOIN and an OUTER JOIN query? I know the two joins may or may not produce the same resultset (depending on data) but I am curious if anyone has come across any difference in terms of performance, generally speaking of course. Should OUTER JOINs be avoided in general unless absolutely necessary? Thanks Billy _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From artful at rogers.com Thu May 5 13:23:37 2005 From: artful at rogers.com (Arthur Fuller) Date: Thu, 05 May 2005 14:23:37 -0400 Subject: [dba-SQLServer] outer joins? In-Reply-To: <000201c550bf$e57590b0$6c7aa8c0@ColbyM6805> References: <000201c550bf$e57590b0$6c7aa8c0@ColbyM6805> Message-ID: <427A64A9.4010905@rogers.com> Well phrased, JWC. Billy's question makes no sense because it assumes an either/or situation, which is not often the case. I will present one simple example: tblEmployees EmployeeID Identity( 0, 1 ) etc/ tblEmployeesChildren EmployeeChildID Identity( 0, 1 ) EmployeeID Integer -- foreign key into tblEmployees It may be interesting to find the employees with no children. OUTER JOIN is perfect for this. SELECT * FROM tblEmployees OUTER JOIN tblEmployeesChildren ON tblEmployees.EmployeeID = tblEmployeesChildren.EmployeeID WHERE tblEmployeesChildren.EmployeeID IS NULL Admittedly an artificial example, but this kind of thing comes up more often than you might initially imagine. Another case: assume a UDF that returns a table containing Sales in the current year. List all customers who have bought nothing this year. OUTER JOIN Customers to the UDF, testing for NULL as above, and there's your list. John W. Colby wrote: >Inner and outer joins simply perform different functions in the overall >scheme of things so you can't really say "avoid them if possible". An inner >join says "only give me records where there is data in both tables". This >is used to enforce rules (for example) - if there is no invoice for this >client, don't return a record in the invoice report - stuff like that. >Outer joins are precisely to allow breaking such rules, allow me to see all >clients, WITH ANY INVOICES... But also show clients where there is no >invoice. > >Which you use depends entirely on your purpose with the query. You may be >able to use an outer join to only display records where there is data in >both tables, but that would require jumping through many hoops I'm guessing. >And AFAIK you simply cannot use an inner join to display data where there is >no data in the related table. > >They are just different animals used for different things. In my mind your >question doesn't make sense. > >John W. Colby >www.ColbyConsulting.com > >Contribute your unused CPU cycles to a good cause: >http://folding.stanford.edu/ > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy Pang >Sent: Wednesday, May 04, 2005 2:48 AM >To: dba-SQLServer at databaseadvisors.com >Subject: [dba-SQLServer] outer joins? > > >Hello: > >Can I ask for the group's opinion about something? Is there any performance > >differences between an INNER JOIN and an OUTER JOIN query? I know the two >joins may or may not produce the same resultset (depending on data) but I am > >curious if anyone has come across any difference in terms of performance, >generally speaking of course. Should OUTER JOINs be avoided in general >unless absolutely necessary? > >Thanks > >Billy > > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 5/4/2005 From tuxedo_man at hotmail.com Thu May 5 21:22:11 2005 From: tuxedo_man at hotmail.com (Billy Pang) Date: Fri, 06 May 2005 02:22:11 +0000 Subject: [dba-SQLServer] outer joins? In-Reply-To: <427A64A9.4010905@rogers.com> Message-ID: got it. thanks for everyone's response. Billy >From: Arthur Fuller >Reply-To: dba-sqlserver at databaseadvisors.com >To: dba-sqlserver at databaseadvisors.com >Subject: Re: [dba-SQLServer] outer joins? >Date: Thu, 05 May 2005 14:23:37 -0400 > >Well phrased, JWC. Billy's question makes no sense because it assumes an >either/or situation, which is not often the case. I will present one simple >example: > >tblEmployees > EmployeeID Identity( 0, 1 ) > etc/ >tblEmployeesChildren > EmployeeChildID Identity( 0, 1 ) > EmployeeID Integer -- foreign key into tblEmployees > >It may be interesting to find the employees with no children. OUTER JOIN is >perfect for this. > >SELECT * >FROM tblEmployees >OUTER JOIN tblEmployeesChildren >ON tblEmployees.EmployeeID = tblEmployeesChildren.EmployeeID >WHERE tblEmployeesChildren.EmployeeID IS NULL > >Admittedly an artificial example, but this kind of thing comes up more >often than you might initially imagine. Another case: assume a UDF that >returns a table containing Sales in the current year. List all customers >who have bought nothing this year. OUTER JOIN Customers to the UDF, testing >for NULL as above, and there's your list. >John W. Colby wrote: > >>Inner and outer joins simply perform different functions in the overall >>scheme of things so you can't really say "avoid them if possible". An >>inner >>join says "only give me records where there is data in both tables". This >>is used to enforce rules (for example) - if there is no invoice for this >>client, don't return a record in the invoice report - stuff like that. >>Outer joins are precisely to allow breaking such rules, allow me to see >>all >>clients, WITH ANY INVOICES... But also show clients where there is no >>invoice. >> >>Which you use depends entirely on your purpose with the query. You may be >>able to use an outer join to only display records where there is data in >>both tables, but that would require jumping through many hoops I'm >>guessing. >>And AFAIK you simply cannot use an inner join to display data where there >>is >>no data in the related table. >> >>They are just different animals used for different things. In my mind >>your >>question doesn't make sense. >> >>John W. Colby >>www.ColbyConsulting.com >> >>Contribute your unused CPU cycles to a good cause: >>http://folding.stanford.edu/ >> >>-----Original Message----- >>From: dba-sqlserver-bounces at databaseadvisors.com >>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy >>Pang >>Sent: Wednesday, May 04, 2005 2:48 AM >>To: dba-SQLServer at databaseadvisors.com >>Subject: [dba-SQLServer] outer joins? >> >> >>Hello: >> >>Can I ask for the group's opinion about something? Is there any >>performance >> >>differences between an INNER JOIN and an OUTER JOIN query? I know the two >>joins may or may not produce the same resultset (depending on data) but I >>am >> >>curious if anyone has come across any difference in terms of performance, >>generally speaking of course. Should OUTER JOINs be avoided in general >>unless absolutely necessary? >> >>Thanks >> >>Billy >> >> >>_______________________________________________ >>dba-SQLServer mailing list >>dba-SQLServer at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>http://www.databaseadvisors.com >> >> >> >> >>_______________________________________________ >>dba-SQLServer mailing list >>dba-SQLServer at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>http://www.databaseadvisors.com >> >> >> >> > > >-- >No virus found in this outgoing message. >Checked by AVG Anti-Virus. >Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 5/4/2005 > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > From ssharkins at bellsouth.net Sat May 7 09:54:41 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Sat, 7 May 2005 10:54:41 -0400 Subject: [dba-SQLServer] ANSI null compliance Message-ID: <20050507145438.HBUK1983.imf16aec.mail.bellsouth.net@SUSANONE> Looking at the DATABASEPROPERTYEX function's ISANSINULLDEFAULT property, I am assuming the following: 1 (True) -- the database's null default meets ANSI compliance 0 (False) -- the database's null default does not meet ANSI compliance Neither of which really tells me what the ANSI compliance is. Since Pubs property is 0, and Pubs does not allow nulls by default, I'm going out on a limb here and deduce that the SQL-92 ANSI null default is to allow nulls. Is this correct? Susan H. From ssharkins at bellsouth.net Sat May 7 10:33:37 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Sat, 7 May 2005 11:33:37 -0400 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <20050507145438.HBUK1983.imf16aec.mail.bellsouth.net@SUSANONE> Message-ID: <20050507153334.HRWQ1983.imf16aec.mail.bellsouth.net@SUSANONE> Well, I confess, I haven't a clue what's going on -- it appears that master's default is to allow nulls -- I'm confused. :( Susan H. Looking at the DATABASEPROPERTYEX function's ISANSINULLDEFAULT property, I am assuming the following: 1 (True) -- the database's null default meets ANSI compliance 0 (False) -- the database's null default does not meet ANSI compliance Neither of which really tells me what the ANSI compliance is. Since Pubs property is 0, and Pubs does not allow nulls by default, I'm going out on a limb here and deduce that the SQL-92 ANSI null default is to allow nulls. Is this correct? Susan H. _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From stuart at lexacorp.com.pg Sat May 7 14:14:37 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Sun, 08 May 2005 05:14:37 +1000 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <20050507145438.HBUK1983.imf16aec.mail.bellsouth.net@SUSANONE> Message-ID: <427DA03D.2467.3DA594F@stuart.lexacorp.com.pg> On 7 May 2005 at 10:54, Susan Harkins wrote: > Looking at the DATABASEPROPERTYEX function's ISANSINULLDEFAULT property, I > am assuming the following: > > 1 (True) -- the database's null default meets ANSI compliance > 0 (False) -- the database's null default does not meet ANSI compliance > > Neither of which really tells me what the ANSI compliance is. Since Pubs > property is 0, and Pubs does not allow nulls by default, I'm going out on a > limb here and deduce that the SQL-92 ANSI null default is to allow nulls. Is > this correct? > Here's more than you every wanted to know :-) http://msdn.microsoft.com/library/default.asp?url=/library/en- us/tsqlref/ts_sp_da-di_8c32.asp ANSI null default When true, CREATE TABLE follows the SQL-92 rules to determine if a column allows null values. See below for the actual rules. MS's "simple" explanation of the rules are: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/tsqlref/ts_set-set_7g32.asp This setting only affects the nullability of new columns when the nullability of the column is not specified in the CREATE TABLE and ALTER TABLE statements. When SET ANSI_NULL_DFLT_OFF is ON, new columns created with the ALTER TABLE and CREATE TABLE statements are, by default, NOT NULL if the nullability status of the column is not explicitly specified. SET ANSI_NULL_DFLT_OFF has no effect on columns created with an explicit NULL or NOT NULL. The Rules from the ANSI-92 standard: Every column has a nullability characteristic of known not nullable or possibly nullable, defined as follows: A column has a nullability characteristic that indicates whether any attempt to store a null value into that column will inevitably raise an exception, or whether any attempt to retrieve a value from that column can ever result in a null value. A column C with CN of a base table T has a nullability characteristic that is known not nullable if and only if either: - there exists at least one constraint that is not deferrable and that simply contains a that contains CN IS NOT NULL or NOT CN IS NULL or RVE IS NOT NULL, where RVE is a that contains a that is simply CN without an intervening that specifies OR and without an intervening that specifies NOT. - C is based on a domain that has a domain constraint that is not deferrable and that simply contains a that contains VALUE IS NOT NULL or NOT VALUE IS NULL without an intervening that specifies OR and without an intervening that specifies NOT. - CN is contained in a non-deferrable whose specifies PRIMARY KEY. Otherwise, a column C is possibly nullable. -- Stuart From ssharkins at bellsouth.net Sat May 7 18:44:14 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Sat, 7 May 2005 19:44:14 -0400 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <427DA03D.2467.3DA594F@stuart.lexacorp.com.pg> Message-ID: <20050507234411.EHMO2061.imf19aec.mail.bellsouth.net@SUSANONE> Well, here's the problem in a nutshell -- the default isn't in compliance with SQL-92, which is Okay. However, Query Analyzer IS -- which would tend to lead one astray. Does anyone know if Enterprise Manager is too because even though the Pubs default returns 0, in EM, if I create a new table/column, it automatically checks Allow Nulls -- which is the opposite of what you'd expect considering the inner non-compliance. But, my thinking is -- if Query Analyzer is in compliance, perhaps EM is too. Or else I'm just terribly baffled by the entire exchange. Susan H. The Rules from the ANSI-92 standard: Every column has a nullability characteristic of known not nullable or possibly nullable, defined as follows: A column has a nullability characteristic that indicates whether any attempt to store a null value into that column will inevitably raise an exception, or whether any attempt to retrieve a value from that column can ever result in a null value. A column C with CN of a base table T has a nullability characteristic that is known From j.frederick at att.net Sun May 8 13:39:22 2005 From: j.frederick at att.net (John Frederick) Date: Sun, 08 May 2005 14:39:22 -0400 Subject: [dba-SQLServer] SQL Server 2000 Compatibility with Windows Server 2003 Message-ID: I'm trying to gen a system to try Microsoft's Commerce Server 2002. I can gen what looks like a good Windows Server 2003 Web Edition. When I try to install SQL Server 2000, I get the first two screens that select the data base engine. Then, I get the little Verisign box(I think it was), then nothing. I've tried a licensed Standard edition and an Evaluation Enterprise edition. Same result. The Commerce Server 2002 documentation clearly indicates that Win Server 2003 and SQL Server 2000 is an acceptable configuration. Can anyone advise on how to get it installed? jif From artful at rogers.com Sun May 8 17:17:46 2005 From: artful at rogers.com (Arthur Fuller) Date: Sun, 08 May 2005 18:17:46 -0400 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <20050507234411.EHMO2061.imf19aec.mail.bellsouth.net@SUSANONE> References: <20050507234411.EHMO2061.imf19aec.mail.bellsouth.net@SUSANONE> Message-ID: <427E900A.3080205@rogers.com> Frankly, I'm not up to chapter on verse on SQL 92, although I read it religiously :) My knee-jerk reaction would be that all columns of whatever type should default to NOT NULL, because IMO, Null columns represent a weakness in our design model. I hate Null columns, unless the client can express a clearly articulated set of circumstances in which said column should be null. For example, we hire a new employee and are not sure sure in which department to place her. Given this objection, I would say, why hire her then? Client could answer, Because her qualifications are so good we don't want her to go elsewhere, we'll find a place for her. Now JWC would slide into his zero'th column argument here, which I flatly reject, but that's another topic. I think all column declarations should default to NOT NULL and force you to do extra work to make them nullable. As I see it, if you can do without the data, then do without it. Conversely, if you need the data then demand it. Just my $.02. Susan Harkins wrote: >Well, here's the problem in a nutshell -- the default isn't in compliance >with SQL-92, which is Okay. However, Query Analyzer IS -- which would tend >to lead one astray. Does anyone know if Enterprise Manager is too because >even though the Pubs default returns 0, in EM, if I create a new >table/column, it automatically checks Allow Nulls -- which is the opposite >of what you'd expect considering the inner non-compliance. But, my thinking >is -- if Query Analyzer is in compliance, perhaps EM is too. > >Or else I'm just terribly baffled by the entire exchange. > >Susan H. > >The Rules from the ANSI-92 standard: > >Every column has a nullability characteristic of known not nullable > or possibly nullable, defined as follows: > > A column has a nullability characteristic that indicates whether > any attempt to store a null value into that column will inevitably > raise an exception, or whether any attempt to retrieve a value > from that column can ever result in a null value. A column C with > CN of a base table T has a nullability characteristic >that is known > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > From stuart at lexacorp.com.pg Sun May 8 22:43:13 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Mon, 09 May 2005 13:43:13 +1000 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <427E900A.3080205@rogers.com> References: <20050507234411.EHMO2061.imf19aec.mail.bellsouth.net@SUSANONE> Message-ID: <427F68F1.7738.13B4912@stuart.lexacorp.com.pg> On 8 May 2005 at 18:17, Arthur Fuller wrote: > Frankly, I'm not up to chapter on verse on SQL 92, although I read it > religiously :) > > My knee-jerk reaction would be that all columns of whatever type should > default to NOT NULL, because IMO, Null columns represent a weakness in > our design model. I hate Null columns, unless the client can express a > clearly articulated set of circumstances in which said column should be > null. For example, we hire a new employee and are not sure sure in which > department to place her. Given this objection, I would say, why hire her > then? Client could answer, Because her qualifications are so good we > don't want her to go elsewhere, we'll find a place for her. > When the new employee says "I've just moved here to start this job. I don't know my home phone number yet, the telco are currently installing it", do you then say "In that case, we can't create an employee record for you and you won't get paid"? > Now JWC would slide into his zero'th column argument here, which I > flatly reject, but that's another topic. > > I think all column declarations should default to NOT NULL and force you > to do extra work to make them nullable. As I see it, if you can do > without the data, then do without it. Conversely, if you need the data > then demand it. > You must live in a very comfortable world where every question has an answer. In my world, data is frequently incomplete and the availability of a null value ("A special value, or mark, that is used to indicate the absence of any data value.") is essential. -- Stuart From cfoust at infostatsystems.com Mon May 9 10:57:50 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 May 2005 08:57:50 -0700 Subject: [dba-SQLServer] ANSI null compliance Message-ID: No don't start that zeroth column argument here, Arthur. It's been beat to death in the D List. Charlotte Foust -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Sunday, May 08, 2005 3:18 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] ANSI null compliance Frankly, I'm not up to chapter on verse on SQL 92, although I read it religiously :) My knee-jerk reaction would be that all columns of whatever type should default to NOT NULL, because IMO, Null columns represent a weakness in our design model. I hate Null columns, unless the client can express a clearly articulated set of circumstances in which said column should be null. For example, we hire a new employee and are not sure sure in which department to place her. Given this objection, I would say, why hire her then? Client could answer, Because her qualifications are so good we don't want her to go elsewhere, we'll find a place for her. Now JWC would slide into his zero'th column argument here, which I flatly reject, but that's another topic. I think all column declarations should default to NOT NULL and force you to do extra work to make them nullable. As I see it, if you can do without the data, then do without it. Conversely, if you need the data then demand it. Just my $.02. Susan Harkins wrote: >Well, here's the problem in a nutshell -- the default isn't in >compliance with SQL-92, which is Okay. However, Query Analyzer IS -- >which would tend to lead one astray. Does anyone know if Enterprise >Manager is too because even though the Pubs default returns 0, in EM, >if I create a new table/column, it automatically checks Allow Nulls -- >which is the opposite of what you'd expect considering the inner >non-compliance. But, my thinking is -- if Query Analyzer is in >compliance, perhaps EM is too. > >Or else I'm just terribly baffled by the entire exchange. > >Susan H. > >The Rules from the ANSI-92 standard: > >Every column has a nullability characteristic of known not nullable > or possibly nullable, defined as follows: > > A column has a nullability characteristic that indicates whether > any attempt to store a null value into that column will inevitably > raise an exception, or whether any attempt to retrieve a value > from that column can ever result in a null value. A column C with > CN of a base table T has a nullability >characteristic that is known > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From artful at rogers.com Mon May 9 16:49:50 2005 From: artful at rogers.com (Arthur Fuller) Date: Mon, 09 May 2005 17:49:50 -0400 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <427F68F1.7738.13B4912@stuart.lexacorp.com.pg> References: <20050507234411.EHMO2061.imf19aec.mail.bellsouth.net@SUSANONE> <427F68F1.7738.13B4912@stuart.lexacorp.com.pg> Message-ID: <427FDAFE.6020708@rogers.com> You have just cited the exceptions which IMO prove my point. Those columns should be nullable for exactly the reasons you mention. My point was that an employee without a surname is a problem, and similarly without an SSN or SIN or their international equivalents. Certain data must be there. Other data is optional. But in the case that you cited (missing home phone) I would try to devise a system (stored proc or whatever) that assigned this row a status of "missing important data" and automatically revisit these faulty rows so they can be corrected. Stuart McLachlan wrote: >On 8 May 2005 at 18:17, Arthur Fuller wrote: > > > >>Frankly, I'm not up to chapter on verse on SQL 92, although I read it >>religiously :) >> >>My knee-jerk reaction would be that all columns of whatever type should >>default to NOT NULL, because IMO, Null columns represent a weakness in >>our design model. I hate Null columns, unless the client can express a >>clearly articulated set of circumstances in which said column should be >>null. For example, we hire a new employee and are not sure sure in which >>department to place her. Given this objection, I would say, why hire her >>then? Client could answer, Because her qualifications are so good we >>don't want her to go elsewhere, we'll find a place for her. >> >> >> >When the new employee says "I've just moved here to start this job. I >don't know my home phone number yet, the telco are currently installing >it", do you then say "In that case, we can't create an employee record for >you and you won't get paid"? > > > >>Now JWC would slide into his zero'th column argument here, which I >>flatly reject, but that's another topic. >> >>I think all column declarations should default to NOT NULL and force you >>to do extra work to make them nullable. As I see it, if you can do >>without the data, then do without it. Conversely, if you need the data >>then demand it. >> >> >> > >You must live in a very comfortable world where every question has an >answer. In my world, data is frequently incomplete and the availability >of a null value ("A special value, or mark, that is used to indicate the >absence of any data value.") is essential. > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 5/6/2005 From artful at rogers.com Mon May 9 16:50:28 2005 From: artful at rogers.com (Arthur Fuller) Date: Mon, 09 May 2005 17:50:28 -0400 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: References: Message-ID: <427FDB24.8060807@rogers.com> I quite agree, Charlotte. Wash my mouth out with soap. Charlotte Foust wrote: >No don't start that zeroth column argument here, Arthur. It's been beat >to death in the D List. > >Charlotte Foust > > >-----Original Message----- >From: Arthur Fuller [mailto:artful at rogers.com] >Sent: Sunday, May 08, 2005 3:18 PM >To: dba-sqlserver at databaseadvisors.com >Subject: Re: [dba-SQLServer] ANSI null compliance > > >Frankly, I'm not up to chapter on verse on SQL 92, although I read it >religiously :) > >My knee-jerk reaction would be that all columns of whatever type should >default to NOT NULL, because IMO, Null columns represent a weakness in >our design model. I hate Null columns, unless the client can express a >clearly articulated set of circumstances in which said column should be >null. For example, we hire a new employee and are not sure sure in which > >department to place her. Given this objection, I would say, why hire her > >then? Client could answer, Because her qualifications are so good we >don't want her to go elsewhere, we'll find a place for her. > >Now JWC would slide into his zero'th column argument here, which I >flatly reject, but that's another topic. > >I think all column declarations should default to NOT NULL and force you > >to do extra work to make them nullable. As I see it, if you can do >without the data, then do without it. Conversely, if you need the data >then demand it. > >Just my $.02. > >Susan Harkins wrote: > > > >>Well, here's the problem in a nutshell -- the default isn't in >>compliance with SQL-92, which is Okay. However, Query Analyzer IS -- >>which would tend to lead one astray. Does anyone know if Enterprise >>Manager is too because even though the Pubs default returns 0, in EM, >>if I create a new table/column, it automatically checks Allow Nulls -- >>which is the opposite of what you'd expect considering the inner >>non-compliance. But, my thinking is -- if Query Analyzer is in >>compliance, perhaps EM is too. >> >>Or else I'm just terribly baffled by the entire exchange. >> >>Susan H. >> >>The Rules from the ANSI-92 standard: >> >>Every column has a nullability characteristic of known not nullable >> or possibly nullable, defined as follows: >> >> A column has a nullability characteristic that indicates >> >> >whether > > >> any attempt to store a null value into that column will >> >> >inevitably > > >> raise an exception, or whether any attempt to retrieve a value >> from that column can ever result in a null value. A column C >> >> >with > > >> CN of a base table T has a nullability >>characteristic that is known >> >>_______________________________________________ >>dba-SQLServer mailing list >>dba-SQLServer at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>http://www.databaseadvisors.com >> >> >> >> >> >> >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 5/6/2005 From accessd at shaw.ca Mon May 9 17:13:13 2005 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 09 May 2005 15:13:13 -0700 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <427FDAFE.6020708@rogers.com> Message-ID: <0IG800344TPZH1@l-daemon> Hi Arthur: I have a database that takes data as it arrives. If the record is not finished; the minimum required data has not been completed, the 'completed' flag field is not set. The uncompleted records will continue to display and 'nag' until either completed or deleted. These records are hosted in a table named 'incomplete'. Though they can still be searched on, they exist in purgatory; they are just not mixed with the general population. Depending on where in the application, the user searches for data, dictates which table is searched first. (With only a few thousand records it really doesn't matter...) My two cents worth. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, May 09, 2005 2:50 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] ANSI null compliance You have just cited the exceptions which IMO prove my point. Those columns should be nullable for exactly the reasons you mention. My point was that an employee without a surname is a problem, and similarly without an SSN or SIN or their international equivalents. Certain data must be there. Other data is optional. But in the case that you cited (missing home phone) I would try to devise a system (stored proc or whatever) that assigned this row a status of "missing important data" and automatically revisit these faulty rows so they can be corrected. Stuart McLachlan wrote: >On 8 May 2005 at 18:17, Arthur Fuller wrote: > > > >>Frankly, I'm not up to chapter on verse on SQL 92, although I read it >>religiously :) >> >>My knee-jerk reaction would be that all columns of whatever type should >>default to NOT NULL, because IMO, Null columns represent a weakness in >>our design model. I hate Null columns, unless the client can express a >>clearly articulated set of circumstances in which said column should be >>null. For example, we hire a new employee and are not sure sure in which >>department to place her. Given this objection, I would say, why hire her >>then? Client could answer, Because her qualifications are so good we >>don't want her to go elsewhere, we'll find a place for her. >> >> >> >When the new employee says "I've just moved here to start this job. I >don't know my home phone number yet, the telco are currently installing >it", do you then say "In that case, we can't create an employee record for >you and you won't get paid"? > > > >>Now JWC would slide into his zero'th column argument here, which I >>flatly reject, but that's another topic. >> >>I think all column declarations should default to NOT NULL and force you >>to do extra work to make them nullable. As I see it, if you can do >>without the data, then do without it. Conversely, if you need the data >>then demand it. >> >> >> > >You must live in a very comfortable world where every question has an >answer. In my world, data is frequently incomplete and the availability >of a null value ("A special value, or mark, that is used to indicate the >absence of any data value.") is essential. > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 5/6/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon May 9 17:36:45 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 May 2005 15:36:45 -0700 Subject: [dba-SQLServer] ANSI null compliance Message-ID: But, Arthur, that's exactly what JC's argument is about, creating a value to represent that missing important data status. Charlotte -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Monday, May 09, 2005 2:50 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] ANSI null compliance You have just cited the exceptions which IMO prove my point. Those columns should be nullable for exactly the reasons you mention. My point was that an employee without a surname is a problem, and similarly without an SSN or SIN or their international equivalents. Certain data must be there. Other data is optional. But in the case that you cited (missing home phone) I would try to devise a system (stored proc or whatever) that assigned this row a status of "missing important data" and automatically revisit these faulty rows so they can be corrected. Stuart McLachlan wrote: >On 8 May 2005 at 18:17, Arthur Fuller wrote: > > > >>Frankly, I'm not up to chapter on verse on SQL 92, although I read it >>religiously :) >> >>My knee-jerk reaction would be that all columns of whatever type >>should >>default to NOT NULL, because IMO, Null columns represent a weakness in >>our design model. I hate Null columns, unless the client can express a >>clearly articulated set of circumstances in which said column should be >>null. For example, we hire a new employee and are not sure sure in which >>department to place her. Given this objection, I would say, why hire her >>then? Client could answer, Because her qualifications are so good we >>don't want her to go elsewhere, we'll find a place for her. >> >> >> >When the new employee says "I've just moved here to start this job. I >don't know my home phone number yet, the telco are currently installing >it", do you then say "In that case, we can't create an employee record for >you and you won't get paid"? > > > >>Now JWC would slide into his zero'th column argument here, which I >>flatly reject, but that's another topic. >> >>I think all column declarations should default to NOT NULL and force >>you >>to do extra work to make them nullable. As I see it, if you can do >>without the data, then do without it. Conversely, if you need the data >>then demand it. >> >> >> > >You must live in a very comfortable world where every question has an >answer. In my world, data is frequently incomplete and the availability >of a null value ("A special value, or mark, that is used to indicate the >absence of any data value.") is essential. > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 5/6/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From stuart at lexacorp.com.pg Mon May 9 17:45:20 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Tue, 10 May 2005 08:45:20 +1000 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <427FDAFE.6020708@rogers.com> References: <427F68F1.7738.13B4912@stuart.lexacorp.com.pg> Message-ID: <428074A0.15715.550ED27@stuart.lexacorp.com.pg> On 9 May 2005 at 17:49, Arthur Fuller wrote: > You have just cited the exceptions which IMO prove my point. Those > columns should be nullable for exactly the reasons you mention. In my experience, far more fields need to be nullable than not, so the default is appropriate in my case. > My point > was that an employee without a surname is a problem, and similarly > without an SSN or SIN or their international equivalents. No such international equivalent in PNG :-( Personnel databases are a nightmare here, not only is ther NO unique identifier such as an SSN (there is no Social Security), people change there names at will (often when someone dies, their nephew will adopt their name etc), in many areas, they use only a few distinct names within one locality and they interchange first and last names ( Tau Buruka is Buruka Tau's son, there are lot's of others with either Tau or Buruka as a last name) A significant proportion of the population, especially the older generation don't even knwo the year of their birth, let alone the date. Very few people have birth certificates. Add the fact that employers frequently recruit staff using the "wantok"* system so a lot of the staff come from the same locality, are related and have similar names. *Wantok = "one talk" literally a person who speaks the same language as you; there being about 800 languages in PNG. Effectively a wantok is a relative or someone who comes from the same tribe/clan/localtiy as you do. Without any form of government social security and being a very triabal society, you have to look after your wantoks and you expect them to look after you. > Certain data > must be there. Other data is optional. But in the case that you cited > (missing home phone) I would try to devise a system (stored proc or > whatever) that assigned this row a status of "missing important data" > and automatically revisit these faulty rows so they can be corrected. > I find it much easier to just use the built in staus of "no data value" ie Null. It is then easy to identify the fields which contain "important data" and list those records with Nulls. No need to develop any system(stored proc or whatever). -- Stuart From artful at rogers.com Mon May 9 18:22:17 2005 From: artful at rogers.com (Arthur Fuller) Date: Mon, 09 May 2005 19:22:17 -0400 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <428074A0.15715.550ED27@stuart.lexacorp.com.pg> References: <427F68F1.7738.13B4912@stuart.lexacorp.com.pg> <428074A0.15715.550ED27@stuart.lexacorp.com.pg> Message-ID: <427FF0A9.1080504@rogers.com> I'll accept that. I just have not worked on such apps recently, except in one case, where I accepted the junk data into a temp table and kept it there until it passed all the validations... which made it brain-dead simple to list the problem records. But in general I have trouble accepting your proposition. Not saying it's incorrect, but only that I have trouble with it.... tblEmployees: EmpID - autonumber/identity Surname - obviously not null (ONN) Given name - ONN Address - ONN or you hire the homeless City - ditto Number of Children -- she doesn't know? Previous Employer -- nullable tblProducts: ProdID - identity Name - how can you sell it without a name? ONN CostPrice - admittedly could be variable but if it's zero then you're going to be a trillionaire if you sell enough of them. Vendor - could be multiple in which case a child table but assuming only one, you gotta buy it from somebody. Re-Order Point - ONN; default it to a dozen or whatever, based on your experience, but don't permit a null. tblOrders: OrderID - identity SalesPerson - if you permit null here then profit sharing is obviously not part of the scheme, in which case why bother recording it? OrderDate - default GetDate() SalesOffice - if you permit null here, why bother recording it? and so on. With Codd, Date, Pascal and Celko, to name just a few experts in the field, I think there is a problem with nullable columns. In general they indicate that the database model has not been sufficiently considered. As to the zero'th row concept, I agree that "unknown and to be addressed later" is a valid concept, but I disagree that its number should be zero. That's all. Why? Because it breaks the relational model's most fundamental premise -- identity keys should be meaningless, and their cardinal and ordinal orders should be irrelevant to the app. This is as fundamental, IMO, as saying that customers whose company name begins with "A" should be in the PK range of 1-1000. I should be able to add "Employee Department Not Yet Assigned" after having added 100 departments. I shouldn't have to make it the zero'th row. IMO that breaks all the rules, and if you believe that kind of falsification you might as well dump the relational model and either go back to Codasyl or forward to OODB. Arthur - s/he doesn't know? Default zero. Previous Empl Stuart McLachlan wrote: >On 9 May 2005 at 17:49, Arthur Fuller wrote: > > > >>You have just cited the exceptions which IMO prove my point. Those >>columns should be nullable for exactly the reasons you mention. >> >> > >In my experience, far more fields need to be nullable than not, so the >default is appropriate in my case. > > > >>My point >>was that an employee without a surname is a problem, and similarly >>without an SSN or SIN or their international equivalents. >> >> > >No such international equivalent in PNG :-( > >Personnel databases are a nightmare here, not only is ther NO unique >identifier such as an SSN (there is no Social Security), people change >there names at will (often when someone dies, their nephew will adopt their >name etc), in many areas, they use only a few distinct names within one >locality and they interchange first and last names ( Tau Buruka is Buruka >Tau's son, there are lot's of others with either Tau or Buruka as a last >name) > >A significant proportion of the population, especially the older generation >don't even knwo the year of their birth, let alone the date. Very few >people have birth certificates. > >Add the fact that employers frequently recruit staff using the "wantok"* >system so a lot of the staff come from the same locality, are related and >have similar names. > >*Wantok = "one talk" literally a person who speaks the same language as >you; there being about 800 languages in PNG. Effectively a wantok is a >relative or someone who comes from the same tribe/clan/localtiy as you do. >Without any form of government social security and being a very triabal >society, you have to look after your wantoks and you expect them to look >after you. > > > >>Certain data >>must be there. Other data is optional. But in the case that you cited >>(missing home phone) I would try to devise a system (stored proc or >>whatever) that assigned this row a status of "missing important data" >>and automatically revisit these faulty rows so they can be corrected. >> >> >> > >I find it much easier to just use the built in staus of "no data value" ie >Null. It is then easy to identify the fields which contain "important >data" and list those records with Nulls. No need to develop any >system(stored proc or whatever). > > > -------------- next part -------------- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 5/6/2005 From stuart at lexacorp.com.pg Mon May 9 18:35:20 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Tue, 10 May 2005 09:35:20 +1000 Subject: [dba-SQLServer] ANSI null compliance In-Reply-To: <427FF0A9.1080504@rogers.com> References: <428074A0.15715.550ED27@stuart.lexacorp.com.pg> Message-ID: <42808058.14613.57EB232@stuart.lexacorp.com.pg> On 9 May 2005 at 19:22, Arthur Fuller wrote: > > With Codd, Date, Pascal and Celko, to name just a few experts in the > field, I think there is a problem with nullable columns. In general they > indicate that the database model has not been sufficiently considered. > ?????????? Codd Rule 3 Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported for representing missing information and inapplicable information in a systematic way, independent of data type. -- Stuart From cfoust at infostatsystems.com Mon May 9 18:45:18 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 May 2005 16:45:18 -0700 Subject: [dba-SQLServer] ANSI null compliance Message-ID: I think the key word there is "experts", Stuart. Unfortunately, real world databases are usually used and commissioned by non-experts and their requirements may be at variance with good practice. Getting paid may involve compromise. ;-> Charlotte Foust -----Original Message----- From: Stuart McLachlan [mailto:stuart at lexacorp.com.pg] Sent: Monday, May 09, 2005 4:35 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] ANSI null compliance On 9 May 2005 at 19:22, Arthur Fuller wrote: > > With Codd, Date, Pascal and Celko, to name just a few experts in the > field, I think there is a problem with nullable columns. In general they > indicate that the database model has not been sufficiently considered. > ?????????? Codd Rule 3 Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported for representing missing information and inapplicable information in a systematic way, independent of data type. -- Stuart _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From roz.clarke at donnslaw.co.uk Tue May 10 04:04:31 2005 From: roz.clarke at donnslaw.co.uk (Roz Clarke) Date: Tue, 10 May 2005 10:04:31 +0100 Subject: [dba-SQLServer] Security & encryption (cross posted to accessd & dba-sql) Message-ID: <61F915314798D311A2F800A0C9C83188072259F8@dibble.observatory.donnslaw.co.uk> Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz -------------- next part -------------- The contents of this message and any attachments are the property of Donns Solicitors and are intended for the confidential use of the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other party without our written consent. If you are not the addressee, please notify us immediately so that we can make arrangements for its return. You should not show this e-mail to any person or take copies as you may be committing a criminal or civil offence for which you may be liable. The statement and opinions expressed in this e-mail message are those of the writer, and do not necessarily represent that of Donns Solicitors. Although any files attached to this e-mail will have been checked with virus protection software prior to transmission, you should carry out your own virus check before opening any attachment. Donns Solicitors does not accept any liability for any damage or loss which may be caused by software viruses... From cfoust at infostatsystems.com Tue May 10 10:13:43 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 10 May 2005 08:13:43 -0700 Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Message-ID: It doesn't really make sense to build a database that the dba is locked out of. I've seen discussions of this HR wish before, but I've never seen a good answer for it. Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 2:05 AM To: 'Access Developers discussion and problem solving'; 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz From roz.clarke at donnslaw.co.uk Tue May 10 10:47:20 2005 From: roz.clarke at donnslaw.co.uk (Roz Clarke) Date: Tue, 10 May 2005 16:47:20 +0100 Subject: [dba-SQLServer] Security & encryption (cross posted to access d &dba-sql) Message-ID: <61F915314798D311A2F800A0C9C8318807225A15@dibble.observatory.donnslaw.co.uk> Well if you've got any evidence as to why it's a bad idea I'd appreciate it - it may help us to see the pitfalls coming even if we can't avoid them! thanks -----Original Message----- From: Charlotte Foust [mailto:cfoust at infostatsystems.com] Sent: 10 May 2005 16:14 To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) It doesn't really make sense to build a database that the dba is locked out of. I've seen discussions of this HR wish before, but I've never seen a good answer for it. Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 2:05 AM To: 'Access Developers discussion and problem solving'; 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com -------------- next part -------------- The contents of this message and any attachments are the property of Donns Solicitors and are intended for the confidential use of the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other party without our written consent. If you are not the addressee, please notify us immediately so that we can make arrangements for its return. You should not show this e-mail to any person or take copies as you may be committing a criminal or civil offence for which you may be liable. The statement and opinions expressed in this e-mail message are those of the writer, and do not necessarily represent that of Donns Solicitors. Although any files attached to this e-mail will have been checked with virus protection software prior to transmission, you should carry out your own virus check before opening any attachment. Donns Solicitors does not accept any liability for any damage or loss which may be caused by software viruses... From cfoust at infostatsystems.com Tue May 10 11:10:12 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 10 May 2005 09:10:12 -0700 Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Message-ID: Encryption makes sense, but the idea of trying to locak a dba out of a database *structure* doesn't. Someone has to administer the blasted thing. Do they have anyone in HR qualified to do so and acceptable to the IT deparment? Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 8:47 AM To: 'dba-sqlserver at databaseadvisors.com' Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Well if you've got any evidence as to why it's a bad idea I'd appreciate it - it may help us to see the pitfalls coming even if we can't avoid them! thanks -----Original Message----- From: Charlotte Foust [mailto:cfoust at infostatsystems.com] Sent: 10 May 2005 16:14 To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) It doesn't really make sense to build a database that the dba is locked out of. I've seen discussions of this HR wish before, but I've never seen a good answer for it. Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 2:05 AM To: 'Access Developers discussion and problem solving'; 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From roz.clarke at donnslaw.co.uk Tue May 10 11:21:53 2005 From: roz.clarke at donnslaw.co.uk (Roz Clarke) Date: Tue, 10 May 2005 17:21:53 +0100 Subject: [dba-SQLServer] Security & encryption (cross posted to access d &dba-sql) Message-ID: <61F915314798D311A2F800A0C9C8318807225A17@dibble.observatory.donnslaw.co.uk> They don't. But I would imagine that if we can demonstrate to them that we can only see encrypted gobbldegook they will accept the need for us to be able to see the structure. -----Original Message----- From: Charlotte Foust [mailto:cfoust at infostatsystems.com] Sent: 10 May 2005 17:10 To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Encryption makes sense, but the idea of trying to locak a dba out of a database *structure* doesn't. Someone has to administer the blasted thing. Do they have anyone in HR qualified to do so and acceptable to the IT deparment? Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 8:47 AM To: 'dba-sqlserver at databaseadvisors.com' Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Well if you've got any evidence as to why it's a bad idea I'd appreciate it - it may help us to see the pitfalls coming even if we can't avoid them! thanks -----Original Message----- From: Charlotte Foust [mailto:cfoust at infostatsystems.com] Sent: 10 May 2005 16:14 To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) It doesn't really make sense to build a database that the dba is locked out of. I've seen discussions of this HR wish before, but I've never seen a good answer for it. Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 2:05 AM To: 'Access Developers discussion and problem solving'; 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com -------------- next part -------------- The contents of this message and any attachments are the property of Donns Solicitors and are intended for the confidential use of the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other party without our written consent. If you are not the addressee, please notify us immediately so that we can make arrangements for its return. You should not show this e-mail to any person or take copies as you may be committing a criminal or civil offence for which you may be liable. The statement and opinions expressed in this e-mail message are those of the writer, and do not necessarily represent that of Donns Solicitors. Although any files attached to this e-mail will have been checked with virus protection software prior to transmission, you should carry out your own virus check before opening any attachment. Donns Solicitors does not accept any liability for any damage or loss which may be caused by software viruses... From fhtapia at gmail.com Tue May 10 11:25:35 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 10 May 2005 09:25:35 -0700 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: References: Message-ID: Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA you'd still be able to get to the data tho... On 5/10/05, Gavin wrote: > > It could very easily be done if the encryption is handled purely in the > front end application. > While possible to encrypt a whole table you'd need to ask yourself how > you'd join on its columns or write your where clauses and still benefit from > the client/server model. > You could even encrypt everything in your SQL Server database but the > overhead in network traffic and client processing would be huge. > > ----- Original Message ----- > *From:* Francisco Tapia > *To:* SQL Server 2k List > *Cc:* roz.clarke at donnslaw.co.uk > *Sent:* Tuesday, May 10, 2005 5:14 PM > *Subject:* Fwd: Security & encryption > > I'm forwarding this message on to this list because I think the author of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility for > confidential data (such as salary information), that is encrypted and that > > neither we nor the network administrators could get into once it's gone > live. Ideally it would be integrated with their current application which > is > Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From fhtapia at gmail.com Tue May 10 11:42:24 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 10 May 2005 09:42:24 -0700 Subject: [dba-SQLServer] Fwd: Security & encryption In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: David Kyle Date: May 10, 2005 9:29 AM Subject: RE: Security & encryption To: SQL Server 2k List The data columns can be encrypted before writing to the database and decrypted on retrieval. Use identity columns as keys to link tables together. Names, salaries etc would be encrypted. -----Original Message----- *From:* bounce-sql2k-6393513 at ls.sswug.org [mailto: bounce-sql2k-6393513 at ls.sswug.org] *On Behalf Of *Francisco Tapia *Sent:* Tuesday, May 10, 2005 5:26 PM *To:* SQL Server 2k List *Cc:* roz.clarke at donnslaw.co.uk; dba-sqlserver at databaseadvisors.com *Subject:* Re: Security & encryption Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA you'd still be able to get to the data tho... On 5/10/05, *Gavin* wrote: It could very easily be done if the encryption is handled purely in the front end application. While possible to encrypt a whole table you'd need to ask yourself how you'd join on its columns or write your where clauses and still benefit from the client/server model. You could even encrypt everything in your SQL Server database but the overhead in network traffic and client processing would be huge. ----- Original Message ----- *From:* Francisco Tapia *To:* SQL Server 2k List *Cc:* roz.clarke at donnslaw.co.uk *Sent:* Tuesday, May 10, 2005 5:14 PM *Subject:* Fwd: Security & encryption I'm forwarding this message on to this list because I think the author of the original post would receive a better response from this group... I am also curious how a dba could encrypt a whole table (or set of tables) and lock themselves out of it.. :| ---------- Forwarded message ---------- From: *Roz Clarke* Date: May 10, 2005 2:04 AM Subject: Security & encryption To: Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From fhtapia at gmail.com Tue May 10 11:47:02 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 10 May 2005 09:47:02 -0700 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: References: Message-ID: So data would only be as safe as the user's memory for their Pwd. So Technically the entire columns or rows could be encrypted within the sproc and the user's choice of pwd but also w/o storing the pwd used. Thinking more technically on this, the entire HR dept would need access to these screens right? or a certain number of people in HR would need access, thus 2 or more people would possibly know the pwd, possibly writting it down in a memo pad and end up storing it under their keyboard... :| ---------- Forwarded message ---------- From: Gavin Date: May 10, 2005 9:33 AM Subject: Re: Security & encryption To: SQL Server 2k List You could make it so part of the encryption key was a value that only the user knew and had to type in every time they used the application so even if you had the decryption code and the data in the database you'd never be able to make clear text again. However if they forgot their key and you had no admin user or key then you'd never get your data back, in a truly secure system there's purposely no way around this. This system would allow you to write the front end application but still not read the data it handled. ----- Original Message ----- *From:* Francisco Tapia *To:* SQL Server 2k List *Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com *Sent:* Tuesday, May 10, 2005 5:25 PM *Subject:* Re: Security & encryption Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA you'd still be able to get to the data tho... On 5/10/05, Gavin wrote: > > It could very easily be done if the encryption is handled purely in the > front end application. > While possible to encrypt a whole table you'd need to ask yourself how > you'd join on its columns or write your where clauses and still benefit from > the client/server model. > You could even encrypt everything in your SQL Server database but the > overhead in network traffic and client processing would be huge. > > ----- Original Message ----- > *From:* Francisco Tapia > *To:* SQL Server 2k List > *Cc:* roz.clarke at donnslaw.co.uk > *Sent:* Tuesday, May 10, 2005 5:14 PM > *Subject:* Fwd: Security & encryption > > I'm forwarding this message on to this list because I think the author of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility for > confidential data (such as salary information), that is encrypted and that > > neither we nor the network administrators could get into once it's gone > live. Ideally it would be integrated with their current application which > is > Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From dmcafee at pacbell.net Tue May 10 12:10:17 2005 From: dmcafee at pacbell.net (dmcafee at pacbell.net) Date: Tue, 10 May 2005 10:10:17 -0700 Subject: [dba-SQLServer] Security & encryption (cross posted to accessd&dba-sql) In-Reply-To: Message-ID: Since HR doesn't have access to the development tools, can't they just be led to believe that it "is" encrypted for the developer? If the Jedi mind trick doesn't work on them, maybe a faux page made up to display "encrypted" data could be show to them. Sometimes, you have to make them think you did what they asked/wanted, even though you know better, like when a sales manager wants to tell you how to make the table structure. David -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Charlotte Foust Sent: Tuesday, May 10, 2005 8:14 AM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd&dba-sql) It doesn't really make sense to build a database that the dba is locked out of. I've seen discussions of this HR wish before, but I've never seen a good answer for it. Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 2:05 AM To: 'Access Developers discussion and problem solving'; 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fhtapia at gmail.com Tue May 10 12:41:01 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 10 May 2005 10:41:01 -0700 Subject: [dba-SQLServer] Security & encryption (cross posted to accessd&dba-sql) In-Reply-To: References: Message-ID: hey... you're describing A sales guy (now over the pond) where I work ;) On 5/10/05, dmcafee at pacbell.net wrote: > > Since HR doesn't have access to the development tools, can't they just be > led to believe that it "is" encrypted for the developer? If the Jedi mind > trick doesn't work on them, maybe a faux page made up to display > "encrypted" > data could be show to them. > > Sometimes, you have to make them think you did what they asked/wanted, > even > though you know better, like when a sales manager wants to tell you how to > make the table structure. > > David > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of > Charlotte Foust > Sent: Tuesday, May 10, 2005 8:14 AM > To: dba-sqlserver at databaseadvisors.com > Subject: RE: [dba-SQLServer] Security & encryption (cross posted to > accessd&dba-sql) > > It doesn't really make sense to build a database that the dba is locked > out of. I've seen discussions of this HR wish before, but I've never > seen a good answer for it. > > Charlotte Foust > > -----Original Message----- > From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] > Sent: Tuesday, May 10, 2005 2:05 AM > To: 'Access Developers discussion and problem solving'; > 'dba-sqlserver at databaseadvisors.com' > Subject: [dba-SQLServer] Security & encryption (cross posted to accessd > &dba-sql) > > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility for > confidential data (such as salary information), that is encrypted and > that neither we nor the network administrators could get into once it's > gone live. Ideally it would be integrated with their current application > which is Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From artful at rogers.com Tue May 10 12:55:28 2005 From: artful at rogers.com (Arthur Fuller) Date: Tue, 10 May 2005 13:55:28 -0400 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: References: Message-ID: <4280F590.6080005@rogers.com> I have been giving this subject some thought of late, since despite my cautions, I found passwords written and hidden beneath the keyboard, and even worse, sticky-notes attached to the side of the monitor! My admittedly tentative plan is this: 1. Devise an algorithm which every user can follow without error. 2. Make every element of said algorithm unique to the person in question, yet also deducible from known facts. Let's take a simple example. Take your mother's birthdate and write it down in yyyymmdd format. For each "1", substitute "@".... i.e. "a" is the first letter of the alphabet but let's disguise it too. For each "0", substitute "O". Prefix all this with the initial of the given name of your kids (if any), in order of their birthdates. For practice, write it down 10 times. That ought to be enough to memorize it, but even if not, there is no need to write down the password. Remember the rules and you can deduce your password anytime. The proposed algorithm may be too simple or perhaps too complex. The salient points are that it should be deducible from knowledge unique to the person in question. It's quite possible for a would-be penetrator to know one or two of these facts, but I think it unlikely that he or she know them all. Thus even if he/she had the formula, it might take a while to determine the password. Arthur Francisco Tapia wrote: >So data would only be as safe as the user's memory for their Pwd. So >Technically the entire columns or rows could be encrypted within the sproc >and the user's choice of pwd but also w/o storing the pwd used. > >Thinking more technically on this, the entire HR dept would need access to >these screens right? or a certain number of people in HR would need access, >thus 2 or more people would possibly know the pwd, possibly writting it down >in a memo pad and end up storing it under their keyboard... :| > > > > >---------- Forwarded message ---------- >From: Gavin >Date: May 10, 2005 9:33 AM >Subject: Re: Security & encryption >To: SQL Server 2k List > >You could make it so part of the encryption key was a value that only the >user knew and had to type in every time they used the application so even if >you had the decryption code and the data in the database you'd never be able >to make clear text again. > However if they forgot their key and you had no admin user or key then >you'd never get your data back, in a truly secure system there's purposely >no way around this. > This system would allow you to write the front end application but still >not read the data it handled. > >----- Original Message ----- >*From:* Francisco Tapia >*To:* SQL Server 2k List >*Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com >*Sent:* Tuesday, May 10, 2005 5:25 PM >*Subject:* Re: Security & encryption > >Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA >you'd still be able to get to the data tho... > > >On 5/10/05, Gavin wrote: > > >>It could very easily be done if the encryption is handled purely in the >>front end application. >> While possible to encrypt a whole table you'd need to ask yourself how >>you'd join on its columns or write your where clauses and still benefit from >>the client/server model. >> You could even encrypt everything in your SQL Server database but the >>overhead in network traffic and client processing would be huge. >> >> ----- Original Message ----- >>*From:* Francisco Tapia >>*To:* SQL Server 2k List >>*Cc:* roz.clarke at donnslaw.co.uk >>*Sent:* Tuesday, May 10, 2005 5:14 PM >>*Subject:* Fwd: Security & encryption >> >>I'm forwarding this message on to this list because I think the author of >>the original post would receive a better response from this group... I am >>also curious how a dba could encrypt a whole table (or set of tables) and >>lock themselves out of it.. :| >> >> >>---------- Forwarded message ---------- >>From: Roz Clarke >>Date: May 10, 2005 2:04 AM >>Subject: Security & encryption >>To: >>Hi all >> >>This may or may not be slightly OT... We have been asked by our HR >>department whether it's possible for us to build a storage facility for >>confidential data (such as salary information), that is encrypted and that >> >>neither we nor the network administrators could get into once it's gone >>live. Ideally it would be integrated with their current application which >>is >>Access 2002 FE / SQL Server 7.0 BE. >> >>How do I build an encrypted database that I can then lock myself out of >>completely?! Without locking everyone else out too (that I've done >>before). >> >>Management are willing to spend some money if necessary. >> >>TIA >> >>Roz >> >> >> >> > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 From DElam at jenkens.com Tue May 10 13:03:20 2005 From: DElam at jenkens.com (Elam, Debbie) Date: Tue, 10 May 2005 13:03:20 -0500 Subject: [dba-SQLServer] Re: Security & encryption Message-ID: <7B1961ED924D1A459E378C9B1BB22B4C02485E1D@natexch.jenkens.com> I use something like this myself. The password is probably secure enough, but I started using tricks with the keyboard layout to "encrypt" it many years ago and even the most obvious passwords are not. Debbie -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Tuesday, May 10, 2005 12:55 PM To: dba-sqlserver at databaseadvisors.com Cc: SQL Server 2k List Subject: Re: [dba-SQLServer] Re: Security & encryption I have been giving this subject some thought of late, since despite my cautions, I found passwords written and hidden beneath the keyboard, and even worse, sticky-notes attached to the side of the monitor! My admittedly tentative plan is this: 1. Devise an algorithm which every user can follow without error. 2. Make every element of said algorithm unique to the person in question, yet also deducible from known facts. Let's take a simple example. Take your mother's birthdate and write it down in yyyymmdd format. For each "1", substitute "@".... i.e. "a" is the first letter of the alphabet but let's disguise it too. For each "0", substitute "O". Prefix all this with the initial of the given name of your kids (if any), in order of their birthdates. For practice, write it down 10 times. That ought to be enough to memorize it, but even if not, there is no need to write down the password. Remember the rules and you can deduce your password anytime. The proposed algorithm may be too simple or perhaps too complex. The salient points are that it should be deducible from knowledge unique to the person in question. It's quite possible for a would-be penetrator to know one or two of these facts, but I think it unlikely that he or she know them all. Thus even if he/she had the formula, it might take a while to determine the password. Arthur Francisco Tapia wrote: >So data would only be as safe as the user's memory for their Pwd. So >Technically the entire columns or rows could be encrypted within the sproc >and the user's choice of pwd but also w/o storing the pwd used. > >Thinking more technically on this, the entire HR dept would need access to >these screens right? or a certain number of people in HR would need access, >thus 2 or more people would possibly know the pwd, possibly writting it down >in a memo pad and end up storing it under their keyboard... :| > > > > >---------- Forwarded message ---------- >From: Gavin >Date: May 10, 2005 9:33 AM >Subject: Re: Security & encryption >To: SQL Server 2k List > >You could make it so part of the encryption key was a value that only the >user knew and had to type in every time they used the application so even if >you had the decryption code and the data in the database you'd never be able >to make clear text again. > However if they forgot their key and you had no admin user or key then >you'd never get your data back, in a truly secure system there's purposely >no way around this. > This system would allow you to write the front end application but still >not read the data it handled. > >----- Original Message ----- >*From:* Francisco Tapia >*To:* SQL Server 2k List >*Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com >*Sent:* Tuesday, May 10, 2005 5:25 PM >*Subject:* Re: Security & encryption > >Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA >you'd still be able to get to the data tho... > > >On 5/10/05, Gavin wrote: > > >>It could very easily be done if the encryption is handled purely in the >>front end application. >> While possible to encrypt a whole table you'd need to ask yourself how >>you'd join on its columns or write your where clauses and still benefit from >>the client/server model. >> You could even encrypt everything in your SQL Server database but the >>overhead in network traffic and client processing would be huge. >> >> ----- Original Message ----- >>*From:* Francisco Tapia >>*To:* SQL Server 2k List >>*Cc:* roz.clarke at donnslaw.co.uk >>*Sent:* Tuesday, May 10, 2005 5:14 PM >>*Subject:* Fwd: Security & encryption >> >>I'm forwarding this message on to this list because I think the author of >>the original post would receive a better response from this group... I am >>also curious how a dba could encrypt a whole table (or set of tables) and >>lock themselves out of it.. :| >> >> >>---------- Forwarded message ---------- >>From: Roz Clarke >>Date: May 10, 2005 2:04 AM >>Subject: Security & encryption >>To: >>Hi all >> >>This may or may not be slightly OT... We have been asked by our HR >>department whether it's possible for us to build a storage facility for >>confidential data (such as salary information), that is encrypted and that >> >>neither we nor the network administrators could get into once it's gone >>live. Ideally it would be integrated with their current application which >>is >>Access 2002 FE / SQL Server 7.0 BE. >> >>How do I build an encrypted database that I can then lock myself out of >>completely?! Without locking everyone else out too (that I've done >>before). >> >>Management are willing to spend some money if necessary. >> >>TIA >> >>Roz >> >> >> >> > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com - JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject to the Attorney-Client Privilege, (2) an attorney work product, or (3) strictly confidential. If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. This communication does not reflect an intention by the sender or the sender's client or principal to conduct a transaction or make any agreement by electronic means. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. From cfoust at infostatsystems.com Tue May 10 13:11:09 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 10 May 2005 11:11:09 -0700 Subject: [dba-SQLServer] Re: Security & encryption Message-ID: LOL I had a user at the US Bureau of Reclamation who did that with his PC login ... In spite of the rules against it. Only he kept it on a sticky note under his mouse pad! Charlotte Foust -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: Tuesday, May 10, 2005 9:47 AM To: SQL Server 2k List Cc: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Re: Security & encryption So data would only be as safe as the user's memory for their Pwd. So Technically the entire columns or rows could be encrypted within the sproc and the user's choice of pwd but also w/o storing the pwd used. Thinking more technically on this, the entire HR dept would need access to these screens right? or a certain number of people in HR would need access, thus 2 or more people would possibly know the pwd, possibly writting it down in a memo pad and end up storing it under their keyboard... :| ---------- Forwarded message ---------- From: Gavin Date: May 10, 2005 9:33 AM Subject: Re: Security & encryption To: SQL Server 2k List You could make it so part of the encryption key was a value that only the user knew and had to type in every time they used the application so even if you had the decryption code and the data in the database you'd never be able to make clear text again. However if they forgot their key and you had no admin user or key then you'd never get your data back, in a truly secure system there's purposely no way around this. This system would allow you to write the front end application but still not read the data it handled. ----- Original Message ----- *From:* Francisco Tapia *To:* SQL Server 2k List *Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com *Sent:* Tuesday, May 10, 2005 5:25 PM *Subject:* Re: Security & encryption Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA you'd still be able to get to the data tho... On 5/10/05, Gavin wrote: > > It could very easily be done if the encryption is handled purely in > the > front end application. > While possible to encrypt a whole table you'd need to ask yourself how > you'd join on its columns or write your where clauses and still benefit from > the client/server model. > You could even encrypt everything in your SQL Server database but the > overhead in network traffic and client processing would be huge. > > ----- Original Message ----- > *From:* Francisco Tapia > *To:* SQL Server 2k List > *Cc:* roz.clarke at donnslaw.co.uk > *Sent:* Tuesday, May 10, 2005 5:14 PM > *Subject:* Fwd: Security & encryption > > I'm forwarding this message on to this list because I think the author > of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility > for confidential data (such as salary information), that is encrypted > and that > > neither we nor the network administrators could get into once it's > gone live. Ideally it would be integrated with their current > application which is Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out > of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue May 10 13:12:20 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 10 May 2005 11:12:20 -0700 Subject: [dba-SQLServer] Security & encryption (cross posted toaccessd&dba-sql) Message-ID: I suspect HR is worried about privacy legal issues, and ducking them like that could get *everyone* in trouble down the road. Charlotte Foust -----Original Message----- From: dmcafee at pacbell.net [mailto:dmcafee at pacbell.net] Sent: Tuesday, May 10, 2005 10:10 AM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted toaccessd&dba-sql) Since HR doesn't have access to the development tools, can't they just be led to believe that it "is" encrypted for the developer? If the Jedi mind trick doesn't work on them, maybe a faux page made up to display "encrypted" data could be show to them. Sometimes, you have to make them think you did what they asked/wanted, even though you know better, like when a sales manager wants to tell you how to make the table structure. David -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Charlotte Foust Sent: Tuesday, May 10, 2005 8:14 AM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Security & encryption (cross posted to accessd&dba-sql) It doesn't really make sense to build a database that the dba is locked out of. I've seen discussions of this HR wish before, but I've never seen a good answer for it. Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Tuesday, May 10, 2005 2:05 AM To: 'Access Developers discussion and problem solving'; 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] Security & encryption (cross posted to accessd &dba-sql) Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Tue May 10 13:17:45 2005 From: jwcolby at colbyconsulting.com (John W. Colby) Date: Tue, 10 May 2005 14:17:45 -0400 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: <4280F590.6080005@rogers.com> Message-ID: <006601c5558c$949a9bf0$6c7aa8c0@ColbyM6805> For my own passwords I use the first letter of a phrase. For example "My new Chevy Ventura minivan is 1 seriously nice car" - MNCVMI1SNC. Pick a phrase with at least 8 words and preferably a number in there. Phrases are much easier to remember than a string of random characters, yet the first letter of each word of a phrase turns into a string of random characters. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, May 10, 2005 1:55 PM To: dba-sqlserver at databaseadvisors.com Cc: SQL Server 2k List Subject: Re: [dba-SQLServer] Re: Security & encryption I have been giving this subject some thought of late, since despite my cautions, I found passwords written and hidden beneath the keyboard, and even worse, sticky-notes attached to the side of the monitor! My admittedly tentative plan is this: 1. Devise an algorithm which every user can follow without error. 2. Make every element of said algorithm unique to the person in question, yet also deducible from known facts. Let's take a simple example. Take your mother's birthdate and write it down in yyyymmdd format. For each "1", substitute "@".... i.e. "a" is the first letter of the alphabet but let's disguise it too. For each "0", substitute "O". Prefix all this with the initial of the given name of your kids (if any), in order of their birthdates. For practice, write it down 10 times. That ought to be enough to memorize it, but even if not, there is no need to write down the password. Remember the rules and you can deduce your password anytime. The proposed algorithm may be too simple or perhaps too complex. The salient points are that it should be deducible from knowledge unique to the person in question. It's quite possible for a would-be penetrator to know one or two of these facts, but I think it unlikely that he or she know them all. Thus even if he/she had the formula, it might take a while to determine the password. Arthur Francisco Tapia wrote: >So data would only be as safe as the user's memory for their Pwd. So >Technically the entire columns or rows could be encrypted within the sproc >and the user's choice of pwd but also w/o storing the pwd used. > >Thinking more technically on this, the entire HR dept would need access >to >these screens right? or a certain number of people in HR would need access, >thus 2 or more people would possibly know the pwd, possibly writting it down >in a memo pad and end up storing it under their keyboard... :| > > > > >---------- Forwarded message ---------- >From: Gavin >Date: May 10, 2005 9:33 AM >Subject: Re: Security & encryption >To: SQL Server 2k List > >You could make it so part of the encryption key was a value that only >the >user knew and had to type in every time they used the application so even if >you had the decryption code and the data in the database you'd never be able >to make clear text again. > However if they forgot their key and you had no admin user or key then >you'd never get your data back, in a truly secure system there's purposely >no way around this. > This system would allow you to write the front end application but still >not read the data it handled. > >----- Original Message ----- >*From:* Francisco Tapia >*To:* SQL Server 2k List >*Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com >*Sent:* Tuesday, May 10, 2005 5:25 PM >*Subject:* Re: Security & encryption > >Oh, I hadn't thought of that. If it is encrypted at the Front end, as a >DBA >you'd still be able to get to the data tho... > > >On 5/10/05, Gavin wrote: > > >>It could very easily be done if the encryption is handled purely in >>the >>front end application. >> While possible to encrypt a whole table you'd need to ask yourself how >>you'd join on its columns or write your where clauses and still benefit from >>the client/server model. >> You could even encrypt everything in your SQL Server database but the >>overhead in network traffic and client processing would be huge. >> >> ----- Original Message ----- >>*From:* Francisco Tapia >>*To:* SQL Server 2k List >>*Cc:* roz.clarke at donnslaw.co.uk >>*Sent:* Tuesday, May 10, 2005 5:14 PM >>*Subject:* Fwd: Security & encryption >> >>I'm forwarding this message on to this list because I think the author >>of >>the original post would receive a better response from this group... I am >>also curious how a dba could encrypt a whole table (or set of tables) and >>lock themselves out of it.. :| >> >> >>---------- Forwarded message ---------- >>From: Roz Clarke >>Date: May 10, 2005 2:04 AM >>Subject: Security & encryption >>To: >>Hi all >> >>This may or may not be slightly OT... We have been asked by our HR >>department whether it's possible for us to build a storage facility >>for confidential data (such as salary information), that is encrypted >>and that >> >>neither we nor the network administrators could get into once it's >>gone live. Ideally it would be integrated with their current >>application which is Access 2002 FE / SQL Server 7.0 BE. >> >>How do I build an encrypted database that I can then lock myself out >>of >>completely?! Without locking everyone else out too (that I've done >>before). >> >>Management are willing to spend some money if necessary. >> >>TIA >> >>Roz >> >> >> >> > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From accessd at shaw.ca Tue May 10 13:52:25 2005 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 10 May 2005 11:52:25 -0700 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: <7B1961ED924D1A459E378C9B1BB22B4C02485E1D@natexch.jenkens.com> Message-ID: <0IGA00B9YF3A42@l-daemon> The government has a stated policy for all passwords and it goes like this: 1. A minimum of 6 characters. 2. Must have mixed Upper and Lower case letters. 3. Must have numbers and letters 4. Must have at least one special character. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Elam, Debbie Sent: Tuesday, May 10, 2005 11:03 AM To: 'dba-sqlserver at databaseadvisors.com' Subject: RE: [dba-SQLServer] Re: Security & encryption I use something like this myself. The password is probably secure enough, but I started using tricks with the keyboard layout to "encrypt" it many years ago and even the most obvious passwords are not. Debbie -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Tuesday, May 10, 2005 12:55 PM To: dba-sqlserver at databaseadvisors.com Cc: SQL Server 2k List Subject: Re: [dba-SQLServer] Re: Security & encryption I have been giving this subject some thought of late, since despite my cautions, I found passwords written and hidden beneath the keyboard, and even worse, sticky-notes attached to the side of the monitor! My admittedly tentative plan is this: 1. Devise an algorithm which every user can follow without error. 2. Make every element of said algorithm unique to the person in question, yet also deducible from known facts. Let's take a simple example. Take your mother's birthdate and write it down in yyyymmdd format. For each "1", substitute "@".... i.e. "a" is the first letter of the alphabet but let's disguise it too. For each "0", substitute "O". Prefix all this with the initial of the given name of your kids (if any), in order of their birthdates. For practice, write it down 10 times. That ought to be enough to memorize it, but even if not, there is no need to write down the password. Remember the rules and you can deduce your password anytime. The proposed algorithm may be too simple or perhaps too complex. The salient points are that it should be deducible from knowledge unique to the person in question. It's quite possible for a would-be penetrator to know one or two of these facts, but I think it unlikely that he or she know them all. Thus even if he/she had the formula, it might take a while to determine the password. Arthur Francisco Tapia wrote: >So data would only be as safe as the user's memory for their Pwd. So >Technically the entire columns or rows could be encrypted within the sproc >and the user's choice of pwd but also w/o storing the pwd used. > >Thinking more technically on this, the entire HR dept would need access to >these screens right? or a certain number of people in HR would need access, >thus 2 or more people would possibly know the pwd, possibly writting it down >in a memo pad and end up storing it under their keyboard... :| > > > > >---------- Forwarded message ---------- >From: Gavin >Date: May 10, 2005 9:33 AM >Subject: Re: Security & encryption >To: SQL Server 2k List > >You could make it so part of the encryption key was a value that only the >user knew and had to type in every time they used the application so even if >you had the decryption code and the data in the database you'd never be able >to make clear text again. > However if they forgot their key and you had no admin user or key then >you'd never get your data back, in a truly secure system there's purposely >no way around this. > This system would allow you to write the front end application but still >not read the data it handled. > >----- Original Message ----- >*From:* Francisco Tapia >*To:* SQL Server 2k List >*Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com >*Sent:* Tuesday, May 10, 2005 5:25 PM >*Subject:* Re: Security & encryption > >Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA >you'd still be able to get to the data tho... > > >On 5/10/05, Gavin wrote: > > >>It could very easily be done if the encryption is handled purely in the >>front end application. >> While possible to encrypt a whole table you'd need to ask yourself how >>you'd join on its columns or write your where clauses and still benefit from >>the client/server model. >> You could even encrypt everything in your SQL Server database but the >>overhead in network traffic and client processing would be huge. >> >> ----- Original Message ----- >>*From:* Francisco Tapia >>*To:* SQL Server 2k List >>*Cc:* roz.clarke at donnslaw.co.uk >>*Sent:* Tuesday, May 10, 2005 5:14 PM >>*Subject:* Fwd: Security & encryption >> >>I'm forwarding this message on to this list because I think the author of >>the original post would receive a better response from this group... I am >>also curious how a dba could encrypt a whole table (or set of tables) and >>lock themselves out of it.. :| >> >> >>---------- Forwarded message ---------- >>From: Roz Clarke >>Date: May 10, 2005 2:04 AM >>Subject: Security & encryption >>To: >>Hi all >> >>This may or may not be slightly OT... We have been asked by our HR >>department whether it's possible for us to build a storage facility for >>confidential data (such as salary information), that is encrypted and that >> >>neither we nor the network administrators could get into once it's gone >>live. Ideally it would be integrated with their current application which >>is >>Access 2002 FE / SQL Server 7.0 BE. >> >>How do I build an encrypted database that I can then lock myself out of >>completely?! Without locking everyone else out too (that I've done >>before). >> >>Management are willing to spend some money if necessary. >> >>TIA >> >>Roz >> >> >> >> > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com - JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject to the Attorney-Client Privilege, (2) an attorney work product, or (3) strictly confidential. If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. This communication does not reflect an intention by the sender or the sender's client or principal to conduct a transaction or make any agreement by electronic means. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From DElam at jenkens.com Tue May 10 13:56:33 2005 From: DElam at jenkens.com (Elam, Debbie) Date: Tue, 10 May 2005 13:56:33 -0500 Subject: [dba-SQLServer] Re: Security & encryption Message-ID: <7B1961ED924D1A459E378C9B1BB22B4C02485E1E@natexch.jenkens.com> Easy on my system. Most of my passwords do this because of my encryption method. It has actually caused problems with programs that forbid special characters in the password. Debbie -----Original Message----- From: Jim Lawrence [mailto:accessd at shaw.ca] Sent: Tuesday, May 10, 2005 1:52 PM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Re: Security & encryption The government has a stated policy for all passwords and it goes like this: 1. A minimum of 6 characters. 2. Must have mixed Upper and Lower case letters. 3. Must have numbers and letters 4. Must have at least one special character. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Elam, Debbie Sent: Tuesday, May 10, 2005 11:03 AM To: 'dba-sqlserver at databaseadvisors.com' Subject: RE: [dba-SQLServer] Re: Security & encryption I use something like this myself. The password is probably secure enough, but I started using tricks with the keyboard layout to "encrypt" it many years ago and even the most obvious passwords are not. Debbie -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Tuesday, May 10, 2005 12:55 PM To: dba-sqlserver at databaseadvisors.com Cc: SQL Server 2k List Subject: Re: [dba-SQLServer] Re: Security & encryption I have been giving this subject some thought of late, since despite my cautions, I found passwords written and hidden beneath the keyboard, and even worse, sticky-notes attached to the side of the monitor! My admittedly tentative plan is this: 1. Devise an algorithm which every user can follow without error. 2. Make every element of said algorithm unique to the person in question, yet also deducible from known facts. Let's take a simple example. Take your mother's birthdate and write it down in yyyymmdd format. For each "1", substitute "@".... i.e. "a" is the first letter of the alphabet but let's disguise it too. For each "0", substitute "O". Prefix all this with the initial of the given name of your kids (if any), in order of their birthdates. For practice, write it down 10 times. That ought to be enough to memorize it, but even if not, there is no need to write down the password. Remember the rules and you can deduce your password anytime. The proposed algorithm may be too simple or perhaps too complex. The salient points are that it should be deducible from knowledge unique to the person in question. It's quite possible for a would-be penetrator to know one or two of these facts, but I think it unlikely that he or she know them all. Thus even if he/she had the formula, it might take a while to determine the password. Arthur Francisco Tapia wrote: >So data would only be as safe as the user's memory for their Pwd. So >Technically the entire columns or rows could be encrypted within the sproc >and the user's choice of pwd but also w/o storing the pwd used. > >Thinking more technically on this, the entire HR dept would need access to >these screens right? or a certain number of people in HR would need access, >thus 2 or more people would possibly know the pwd, possibly writting it down >in a memo pad and end up storing it under their keyboard... :| > > > > >---------- Forwarded message ---------- >From: Gavin >Date: May 10, 2005 9:33 AM >Subject: Re: Security & encryption >To: SQL Server 2k List > >You could make it so part of the encryption key was a value that only the >user knew and had to type in every time they used the application so even if >you had the decryption code and the data in the database you'd never be able >to make clear text again. > However if they forgot their key and you had no admin user or key then >you'd never get your data back, in a truly secure system there's purposely >no way around this. > This system would allow you to write the front end application but still >not read the data it handled. > >----- Original Message ----- >*From:* Francisco Tapia >*To:* SQL Server 2k List >*Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com >*Sent:* Tuesday, May 10, 2005 5:25 PM >*Subject:* Re: Security & encryption > >Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA >you'd still be able to get to the data tho... > > >On 5/10/05, Gavin wrote: > > >>It could very easily be done if the encryption is handled purely in the >>front end application. >> While possible to encrypt a whole table you'd need to ask yourself how >>you'd join on its columns or write your where clauses and still benefit from >>the client/server model. >> You could even encrypt everything in your SQL Server database but the >>overhead in network traffic and client processing would be huge. >> >> ----- Original Message ----- >>*From:* Francisco Tapia >>*To:* SQL Server 2k List >>*Cc:* roz.clarke at donnslaw.co.uk >>*Sent:* Tuesday, May 10, 2005 5:14 PM >>*Subject:* Fwd: Security & encryption >> >>I'm forwarding this message on to this list because I think the author of >>the original post would receive a better response from this group... I am >>also curious how a dba could encrypt a whole table (or set of tables) and >>lock themselves out of it.. :| >> >> >>---------- Forwarded message ---------- >>From: Roz Clarke >>Date: May 10, 2005 2:04 AM >>Subject: Security & encryption >>To: >>Hi all >> >>This may or may not be slightly OT... We have been asked by our HR >>department whether it's possible for us to build a storage facility for >>confidential data (such as salary information), that is encrypted and that >> >>neither we nor the network administrators could get into once it's gone >>live. Ideally it would be integrated with their current application which >>is >>Access 2002 FE / SQL Server 7.0 BE. >> >>How do I build an encrypted database that I can then lock myself out of >>completely?! Without locking everyone else out too (that I've done >>before). >> >>Management are willing to spend some money if necessary. >> >>TIA >> >>Roz >> >> >> >> > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com - JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject to the Attorney-Client Privilege, (2) an attorney work product, or (3) strictly confidential. If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. This communication does not reflect an intention by the sender or the sender's client or principal to conduct a transaction or make any agreement by electronic means. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com - JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject to the Attorney-Client Privilege, (2) an attorney work product, or (3) strictly confidential. If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. This communication does not reflect an intention by the sender or the sender's client or principal to conduct a transaction or make any agreement by electronic means. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. From fhtapia at gmail.com Tue May 10 13:59:42 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 10 May 2005 11:59:42 -0700 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: References: Message-ID: Very true. unless of course your where clause would be encrypted as well such as: Select dbo.udfDeCrypt(BankAccountNr, @key) Where SSN = dbo.udfEnCrypt(@SSN, @key) would this key be required for all data access per use or stored in memory at the FE? On 5/10/05, Ian Pettman wrote: > > I had a thought that may be you could encrypt the data but leave the > indexes unencrypted ? but that would not work as it would be trivial to: > > select BankAccountNr Where BankAccountNr = '123456789' > > I think you have to lock the vault door ? not shred the notes inside! > > HTH > > Ian > > ------------------------------ > > *From:* bounce-sql2k-8812377 at ls.datareturn.com [mailto: > bounce-sql2k-8812377 at ls.datareturn.com] *On Behalf Of *Goutam Paruchuri > *Sent:* 10 May 2005 18:58 > *To:* SQL Server 2k List > *Cc:* roz.clarke at donnslaw.co.uk > *Subject:* RE: Security & encryption > > Encryption concepts like PGP could work in this case. > > The best way is to encrypt the data in the database. (Though the database > is readable , the data would not make sense to anyone except the user using > the application. > > As others have said, threat analysis needs to be done to enfore type of > security you need.. > > - Goutam > > ------------------------------ > > *From:* bounce-sql2k-9077134 at ls.sswug.org [mailto: > bounce-sql2k-9077134 at ls.sswug.org] *On Behalf Of *Francisco Tapia > *Sent:* Tuesday, May 10, 2005 12:15 PM > *To:* SQL Server 2k List > *Cc:* roz.clarke at donnslaw.co.uk > *Subject:* Fwd: Security & encryption > > I'm forwarding this message on to this list because I think the author of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: *Roz Clarke* Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility for > confidential data (such as salary information), that is encrypted and that > > neither we nor the network administrators could get into once it's gone > live. Ideally it would be integrated with their current application which > is > Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From artful at rogers.com Tue May 10 15:41:51 2005 From: artful at rogers.com (Arthur Fuller) Date: Tue, 10 May 2005 16:41:51 -0400 Subject: [dba-SQLServer] Security & encryption (cross posted to accessd&dba-sql) In-Reply-To: References: Message-ID: <42811C8F.7080807@rogers.com> Your reply reminds me of words of wisdom which were the motto of Nantucket (Clipper) 's development team -- "Ask them what they want, then deliver what they need." Classic example in this case being the addition of the VALID keyword to the xBASE language.... opened a thousand new doorways! dmcafee at pacbell.net wrote: >Since HR doesn't have access to the development tools, can't they just be >led to believe that it "is" encrypted for the developer? If the Jedi mind >trick doesn't work on them, maybe a faux page made up to display "encrypted" >data could be show to them. > >Sometimes, you have to make them think you did what they asked/wanted, even >though you know better, like when a sales manager wants to tell you how to >make the table structure. > >David > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of >Charlotte Foust >Sent: Tuesday, May 10, 2005 8:14 AM >To: dba-sqlserver at databaseadvisors.com >Subject: RE: [dba-SQLServer] Security & encryption (cross posted to >accessd&dba-sql) > > >It doesn't really make sense to build a database that the dba is locked >out of. I've seen discussions of this HR wish before, but I've never >seen a good answer for it. > >Charlotte Foust > > >-----Original Message----- >From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] >Sent: Tuesday, May 10, 2005 2:05 AM >To: 'Access Developers discussion and problem solving'; >'dba-sqlserver at databaseadvisors.com' >Subject: [dba-SQLServer] Security & encryption (cross posted to accessd >&dba-sql) > > >Hi all > >This may or may not be slightly OT... We have been asked by our HR >department whether it's possible for us to build a storage facility for >confidential data (such as salary information), that is encrypted and >that neither we nor the network administrators could get into once it's >gone live. Ideally it would be integrated with their current application >which is Access 2002 FE / SQL Server 7.0 BE. > >How do I build an encrypted database that I can then lock myself out of >completely?! Without locking everyone else out too (that I've done >before). > >Management are willing to spend some money if necessary. > >TIA > >Roz >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 From stuart at lexacorp.com.pg Tue May 10 17:29:29 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 11 May 2005 08:29:29 +1000 Subject: [dba-SQLServer] Re: Security & encryption In-Reply-To: References: Message-ID: <4281C269.2613.A68B577@stuart.lexacorp.com.pg> On 10 May 2005 at 9:47, Francisco Tapia wrote: > So data would only be as safe as the user's memory for their Pwd. So > Technically the entire columns or rows could be encrypted within the sproc > and the user's choice of pwd but also w/o storing the pwd used. > > Thinking more technically on this, the entire HR dept would need access to > these screens right? or a certain number of people in HR would need access, > thus 2 or more people would possibly know the pwd, possibly writting it down > in a memo pad and end up storing it under their keyboard... :| > Yep, wetware is always the weakest component in security matters. -- Stuart From roz.clarke at donnslaw.co.uk Wed May 11 08:59:31 2005 From: roz.clarke at donnslaw.co.uk (Roz Clarke) Date: Wed, 11 May 2005 14:59:31 +0100 Subject: [dba-SQLServer] RE: Security & encryption Message-ID: <61F915314798D311A2F800A0C9C8318807225A28@dibble.observatory.donnslaw.co.uk> I think we will go with encryption at the field level - realistically, we need to be able to access the table structure, but not to see certain peices of information. Nothing that they want to keep us away from will involve relationships so encrypting the data on entry shouldn't cause us any problems. -----Original Message----- From: Steve Carter [mailto:steve.carter at donnslaw.co.uk] Sent: 11 May 2005 11:49 To: roz.clarke at donnslaw.co.uk Subject: Fw: Security & encryption ----- Original Message ----- From: Francisco Tapia To: SQL Server 2k List Cc: roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com Sent: Tuesday, May 10, 2005 5:25 PM Subject: Re: Security & encryption Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA you'd still be able to get to the data tho... On 5/10/05, Gavin > wrote: It could very easily be done if the encryption is handled purely in the front end application. While possible to encrypt a whole table you'd need to ask yourself how you'd join on its columns or write your where clauses and still benefit from the client/server model. You could even encrypt everything in your SQL Server database but the overhead in network traffic and client processing would be huge. ----- Original Message ----- From: Francisco Tapia To: SQL Server 2k List Cc: roz.clarke at donnslaw.co.uk Sent: Tuesday, May 10, 2005 5:14 PM Subject: Fwd: Security & encryption I'm forwarding this message on to this list because I think the author of the original post would receive a better response from this group... I am also curious how a dba could encrypt a whole table (or set of tables) and lock themselves out of it.. :| ---------- Forwarded message ---------- From: Roz Clarke > Date: May 10, 2005 2:04 AM Subject: Security & encryption To: Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... -------------- next part -------------- The contents of this message and any attachments are the property of Donns Solicitors and are intended for the confidential use of the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other party without our written consent. If you are not the addressee, please notify us immediately so that we can make arrangements for its return. You should not show this e-mail to any person or take copies as you may be committing a criminal or civil offence for which you may be liable. The statement and opinions expressed in this e-mail message are those of the writer, and do not necessarily represent that of Donns Solicitors. Although any files attached to this e-mail will have been checked with virus protection software prior to transmission, you should carry out your own virus check before opening any attachment. Donns Solicitors does not accept any liability for any damage or loss which may be caused by software viruses... From jwcolby at colbyconsulting.com Wed May 11 09:04:42 2005 From: jwcolby at colbyconsulting.com (John W. Colby) Date: Wed, 11 May 2005 10:04:42 -0400 Subject: [dba-SQLServer] RE: Security & encryption In-Reply-To: <61F915314798D311A2F800A0C9C8318807225A28@dibble.observatory.donnslaw.co.uk> Message-ID: <002d01c55632$61360190$6c7aa8c0@ColbyM6805> And if it hasn't been mentioned already, sorts by those values won't work, at least at the query level. You may get it to work at the report level after the data has been unencrypted. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Roz Clarke Sent: Wednesday, May 11, 2005 10:00 AM To: 'mailto:sql2k at ls.sswug.org' Cc: 'dba-sqlserver at databaseadvisors.com' Subject: [dba-SQLServer] RE: Security & encryption I think we will go with encryption at the field level - realistically, we need to be able to access the table structure, but not to see certain peices of information. Nothing that they want to keep us away from will involve relationships so encrypting the data on entry shouldn't cause us any problems. -----Original Message----- From: Steve Carter [mailto:steve.carter at donnslaw.co.uk] Sent: 11 May 2005 11:49 To: roz.clarke at donnslaw.co.uk Subject: Fw: Security & encryption ----- Original Message ----- From: Francisco Tapia To: SQL Server 2k List Cc: roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com Sent: Tuesday, May 10, 2005 5:25 PM Subject: Re: Security & encryption Oh, I hadn't thought of that. If it is encrypted at the Front end, as a DBA you'd still be able to get to the data tho... On 5/10/05, Gavin > wrote: It could very easily be done if the encryption is handled purely in the front end application. While possible to encrypt a whole table you'd need to ask yourself how you'd join on its columns or write your where clauses and still benefit from the client/server model. You could even encrypt everything in your SQL Server database but the overhead in network traffic and client processing would be huge. ----- Original Message ----- From: Francisco Tapia To: SQL Server 2k List Cc: roz.clarke at donnslaw.co.uk Sent: Tuesday, May 10, 2005 5:14 PM Subject: Fwd: Security & encryption I'm forwarding this message on to this list because I think the author of the original post would receive a better response from this group... I am also curious how a dba could encrypt a whole table (or set of tables) and lock themselves out of it.. :| ---------- Forwarded message ---------- From: Roz Clarke > Date: May 10, 2005 2:04 AM Subject: Security & encryption To: Hi all This may or may not be slightly OT... We have been asked by our HR department whether it's possible for us to build a storage facility for confidential data (such as salary information), that is encrypted and that neither we nor the network administrators could get into once it's gone live. Ideally it would be integrated with their current application which is Access 2002 FE / SQL Server 7.0 BE. How do I build an encrypted database that I can then lock myself out of completely?! Without locking everyone else out too (that I've done before). Management are willing to spend some money if necessary. TIA Roz -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From fhtapia at gmail.com Wed May 11 09:59:36 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Wed, 11 May 2005 07:59:36 -0700 Subject: [dba-SQLServer] Fwd: Security & encryption In-Reply-To: References: Message-ID: Well this seems most appropriate, just hire a dba you can trust :) ---------- Forwarded message ---------- From: Mark Allison Date: May 11, 2005 2:12 AM Subject: Re: Security & encryption To: SQL Server 2k List Francisco, I would approach this by recommending the HR department only encrypt the data that really needs to be encrypted. This data should then be encrypted at the front end using a private/public key algorithm akin to PGP. Then, an entire department will be able to view the data with their own keys, and you could also encrypt the data to a "master" key used by HR in case passwords get forgotten. There are APIs that allow a front-end developer to easily accomplish this. This way, the data can be joined on using keys, etc. However queries against encrypted data will not be possible without retrieving the entire data set to the client, decrypting and then performing the work. For example queries like, show me employees paid over 100K that take 5 or more days sick a year would be network, db and client intensive. Indeed, the client machines may not even be able to cope with this kind of question if the dataset is large. I don't know how much data you have, but this would need to be thought through, including scalability. How much will the data grow over the next n years? The other solution is to not encrypt the data, but secure the db server and trust your DBAs. I worked in a large law firm (the world's largest, in fact) and had access to all employee data because the HR dept trusted the DBA team. However there were restrictions put in place such as: a) The SQL Server was behind a firewall b) The DBA and HR workstations were filtered by the firewall, everyone else was denied access through port 1433 c) Logins inside SQL Server were only given to DBAs and HR I prefer the latter approach as encryption can be messy and labour intensive when used in a DB. I think encryption is great for things like email and documents, but searching and indexing this information becomes difficult. Mark. On 10/05/05, Francisco Tapia wrote: > > I'm forwarding this message on to this list because I think the author of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke < roz.clarke at donnslaw.co.uk> > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility for > confidential data (such as salary information), that is encrypted and that > > neither we nor the network administrators could get into once it's gone > live. Ideally it would be integrated with their current application which > is > Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From roz.clarke at donnslaw.co.uk Wed May 11 10:31:01 2005 From: roz.clarke at donnslaw.co.uk (Roz Clarke) Date: Wed, 11 May 2005 16:31:01 +0100 Subject: [dba-SQLServer] Fwd: Security & encryption Message-ID: <61F915314798D311A2F800A0C9C8318807225A2B@dibble.observatory.donnslaw.co.uk> I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: 11 May 2005 16:00 To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Fwd: Security & encryption Well this seems most appropriate, just hire a dba you can trust :) ---------- Forwarded message ---------- From: Mark Allison Date: May 11, 2005 2:12 AM Subject: Re: Security & encryption To: SQL Server 2k List Francisco, I would approach this by recommending the HR department only encrypt the data that really needs to be encrypted. This data should then be encrypted at the front end using a private/public key algorithm akin to PGP. Then, an entire department will be able to view the data with their own keys, and you could also encrypt the data to a "master" key used by HR in case passwords get forgotten. There are APIs that allow a front-end developer to easily accomplish this. This way, the data can be joined on using keys, etc. However queries against encrypted data will not be possible without retrieving the entire data set to the client, decrypting and then performing the work. For example queries like, show me employees paid over 100K that take 5 or more days sick a year would be network, db and client intensive. Indeed, the client machines may not even be able to cope with this kind of question if the dataset is large. I don't know how much data you have, but this would need to be thought through, including scalability. How much will the data grow over the next n years? The other solution is to not encrypt the data, but secure the db server and trust your DBAs. I worked in a large law firm (the world's largest, in fact) and had access to all employee data because the HR dept trusted the DBA team. However there were restrictions put in place such as: a) The SQL Server was behind a firewall b) The DBA and HR workstations were filtered by the firewall, everyone else was denied access through port 1433 c) Logins inside SQL Server were only given to DBAs and HR I prefer the latter approach as encryption can be messy and labour intensive when used in a DB. I think encryption is great for things like email and documents, but searching and indexing this information becomes difficult. Mark. On 10/05/05, Francisco Tapia wrote: > > I'm forwarding this message on to this list because I think the author > of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke < roz.clarke at donnslaw.co.uk> > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility > for confidential data (such as salary information), that is encrypted > and that > > neither we nor the network administrators could get into once it's > gone live. Ideally it would be integrated with their current > application which is Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out > of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com -------------- next part -------------- The contents of this message and any attachments are the property of Donns Solicitors and are intended for the confidential use of the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other party without our written consent. If you are not the addressee, please notify us immediately so that we can make arrangements for its return. You should not show this e-mail to any person or take copies as you may be committing a criminal or civil offence for which you may be liable. The statement and opinions expressed in this e-mail message are those of the writer, and do not necessarily represent that of Donns Solicitors. Although any files attached to this e-mail will have been checked with virus protection software prior to transmission, you should carry out your own virus check before opening any attachment. Donns Solicitors does not accept any liability for any damage or loss which may be caused by software viruses... From gareth.alexander at donnslaw.co.uk Wed May 11 10:58:11 2005 From: gareth.alexander at donnslaw.co.uk (Gareth Alexander) Date: Wed, 11 May 2005 16:58:11 +0100 Subject: [dba-SQLServer] Fwd: Security & encryption Message-ID: <61F915314798D311A2F800A0C9C831880621DCA4@dibble.observatory.donnslaw.co.uk> No, we can't trust her HR -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: 11-May-2005 16:31 To: 'dba-sqlserver at databaseadvisors.com' Subject: RE: [dba-SQLServer] Fwd: Security & encryption I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: 11 May 2005 16:00 To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Fwd: Security & encryption Well this seems most appropriate, just hire a dba you can trust :) ---------- Forwarded message ---------- From: Mark Allison Date: May 11, 2005 2:12 AM Subject: Re: Security & encryption To: SQL Server 2k List Francisco, I would approach this by recommending the HR department only encrypt the data that really needs to be encrypted. This data should then be encrypted at the front end using a private/public key algorithm akin to PGP. Then, an entire department will be able to view the data with their own keys, and you could also encrypt the data to a "master" key used by HR in case passwords get forgotten. There are APIs that allow a front-end developer to easily accomplish this. This way, the data can be joined on using keys, etc. However queries against encrypted data will not be possible without retrieving the entire data set to the client, decrypting and then performing the work. For example queries like, show me employees paid over 100K that take 5 or more days sick a year would be network, db and client intensive. Indeed, the client machines may not even be able to cope with this kind of question if the dataset is large. I don't know how much data you have, but this would need to be thought through, including scalability. How much will the data grow over the next n years? The other solution is to not encrypt the data, but secure the db server and trust your DBAs. I worked in a large law firm (the world's largest, in fact) and had access to all employee data because the HR dept trusted the DBA team. However there were restrictions put in place such as: a) The SQL Server was behind a firewall b) The DBA and HR workstations were filtered by the firewall, everyone else was denied access through port 1433 c) Logins inside SQL Server were only given to DBAs and HR I prefer the latter approach as encryption can be messy and labour intensive when used in a DB. I think encryption is great for things like email and documents, but searching and indexing this information becomes difficult. Mark. On 10/05/05, Francisco Tapia wrote: > > I'm forwarding this message on to this list because I think the author > of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke < roz.clarke at donnslaw.co.uk> > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility > for confidential data (such as salary information), that is encrypted > and that > > neither we nor the network administrators could get into once it's > gone live. Ideally it would be integrated with their current > application which is Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out > of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com -------------- next part -------------- The contents of this message and any attachments are the property of Donns Solicitors and are intended for the confidential use of the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other party without our written consent. If you are not the addressee, please notify us immediately so that we can make arrangements for its return. You should not show this e-mail to any person or take copies as you may be committing a criminal or civil offence for which you may be liable. The statement and opinions expressed in this e-mail message are those of the writer, and do not necessarily represent that of Donns Solicitors. Although any files attached to this e-mail will have been checked with virus protection software prior to transmission, you should carry out your own virus check before opening any attachment. Donns Solicitors does not accept any liability for any damage or loss which may be caused by software viruses... From cfoust at infostatsystems.com Wed May 11 12:14:55 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 11 May 2005 10:14:55 -0700 Subject: [dba-SQLServer] Fwd: Security & encryption Message-ID: Somehow, I think you're going to have to work out a compromise with them. Could you promise not to peek, wear a blindfold when the table is open, point out that they get a dba with the database, not one from column A OR one from column B? Charlotte Foust -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Wednesday, May 11, 2005 8:31 AM To: 'dba-sqlserver at databaseadvisors.com' Subject: RE: [dba-SQLServer] Fwd: Security & encryption I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: 11 May 2005 16:00 To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Fwd: Security & encryption Well this seems most appropriate, just hire a dba you can trust :) ---------- Forwarded message ---------- From: Mark Allison Date: May 11, 2005 2:12 AM Subject: Re: Security & encryption To: SQL Server 2k List Francisco, I would approach this by recommending the HR department only encrypt the data that really needs to be encrypted. This data should then be encrypted at the front end using a private/public key algorithm akin to PGP. Then, an entire department will be able to view the data with their own keys, and you could also encrypt the data to a "master" key used by HR in case passwords get forgotten. There are APIs that allow a front-end developer to easily accomplish this. This way, the data can be joined on using keys, etc. However queries against encrypted data will not be possible without retrieving the entire data set to the client, decrypting and then performing the work. For example queries like, show me employees paid over 100K that take 5 or more days sick a year would be network, db and client intensive. Indeed, the client machines may not even be able to cope with this kind of question if the dataset is large. I don't know how much data you have, but this would need to be thought through, including scalability. How much will the data grow over the next n years? The other solution is to not encrypt the data, but secure the db server and trust your DBAs. I worked in a large law firm (the world's largest, in fact) and had access to all employee data because the HR dept trusted the DBA team. However there were restrictions put in place such as: a) The SQL Server was behind a firewall b) The DBA and HR workstations were filtered by the firewall, everyone else was denied access through port 1433 c) Logins inside SQL Server were only given to DBAs and HR I prefer the latter approach as encryption can be messy and labour intensive when used in a DB. I think encryption is great for things like email and documents, but searching and indexing this information becomes difficult. Mark. On 10/05/05, Francisco Tapia wrote: > > I'm forwarding this message on to this list because I think the author > of > the original post would receive a better response from this group... I am > also curious how a dba could encrypt a whole table (or set of tables) and > lock themselves out of it.. :| > > > ---------- Forwarded message ---------- > From: Roz Clarke < roz.clarke at donnslaw.co.uk> > Date: May 10, 2005 2:04 AM > Subject: Security & encryption > To: > Hi all > > This may or may not be slightly OT... We have been asked by our HR > department whether it's possible for us to build a storage facility > for confidential data (such as salary information), that is encrypted > and that > > neither we nor the network administrators could get into once it's > gone live. Ideally it would be integrated with their current > application which is Access 2002 FE / SQL Server 7.0 BE. > > How do I build an encrypted database that I can then lock myself out > of > completely?! Without locking everyone else out too (that I've done > before). > > Management are willing to spend some money if necessary. > > TIA > > Roz > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From nick at frasiervan.com Wed May 11 12:59:44 2005 From: nick at frasiervan.com (nicholas van) Date: Wed, 11 May 2005 10:59:44 -0700 Subject: [dba-SQLServer] Fwd: Security & encryption Message-ID: <200505111059.AA673316984@frasiervan.com> Mark has covered most of the main design points. As always, Higher Security = Greater Inconvenience I think it may be interesting to clarify what is meant by not letting the sysadmins and DBA get into the data. Even if the data itself is encrypted the DBA and System adminstrators will have the enough access to seriously compromise the integrity of the data. Even if you cannot know the exact data because it is encrypted, we are talking about people who can effectively deny access to all others, or in other ways render the data meaningless. As was pointed out with the encyption scheme, the most important point of control is to make sure that the people who have access to the encrypted data do not also have access to the encryption keys. Where we are right now we deal with some confidential data and we make sure the people with the devryption key access do not have database access, and vice versa. ---------- Original Message ---------------------------------- From: "Charlotte Foust" Reply-To: dba-sqlserver at databaseadvisors.com Date: Wed, 11 May 2005 10:14:55 -0700 >Somehow, I think you're going to have to work out a compromise with >them. Could you promise not to peek, wear a blindfold when the table is >open, point out that they get a dba with the database, not one from >column A OR one from column B? > >Charlotte Foust > > >-----Original Message----- >From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] >Sent: Wednesday, May 11, 2005 8:31 AM >To: 'dba-sqlserver at databaseadvisors.com' >Subject: RE: [dba-SQLServer] Fwd: Security & encryption > > >I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( > From JRojas at tnco-inc.com Wed May 11 15:11:52 2005 From: JRojas at tnco-inc.com (Joe Rojas) Date: Wed, 11 May 2005 16:11:52 -0400 Subject: [dba-SQLServer] Audit Trails Message-ID: <0CC84C9461AE6445AD5A602001C41C4B05A2B0@mercury.tnco-inc.com> Hi All, How can I go about creating audit trails for a table in SS7.5? What I would like to be able to see is if a user updates a row I could see: EmpID DateChanged ColumnName OldValue NewValue Thanks! JR This electronic transmission is strictly confidential to TNCO, Inc. and intended solely for the addressee. It may contain information which is covered by legal, professional, or other privileges. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on behalf of the addressee, you must not retain, disclose in any form, copy, or take any action in reliance on this transmission. If you have received this transmission in error, please notify the sender as soon as possible and destroy this message. While TNCO, Inc. uses virus protection, the recipient should check this email and any attachments for the presence of viruses. TNCO, Inc. accepts no liability for any damage caused by any virus transmitted by this email. From cfoust at infostatsystems.com Wed May 11 15:28:09 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 11 May 2005 13:28:09 -0700 Subject: [dba-SQLServer] Fwd: Security & encryption Message-ID: Certainly, but that ability to render the data meaningless or deny access ALWAYS exists in the dba, regardless of whether the data is encrypted. If you can't trust a dba or you won't trust one to protect your interests and your data, then you should be keeping your data someplace other than in a database. Charlotte Foust -----Original Message----- From: nicholas van [mailto:nick at frasiervan.com] Sent: Wednesday, May 11, 2005 11:00 AM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Fwd: Security & encryption Mark has covered most of the main design points. As always, Higher Security = Greater Inconvenience I think it may be interesting to clarify what is meant by not letting the sysadmins and DBA get into the data. Even if the data itself is encrypted the DBA and System adminstrators will have the enough access to seriously compromise the integrity of the data. Even if you cannot know the exact data because it is encrypted, we are talking about people who can effectively deny access to all others, or in other ways render the data meaningless. As was pointed out with the encyption scheme, the most important point of control is to make sure that the people who have access to the encrypted data do not also have access to the encryption keys. Where we are right now we deal with some confidential data and we make sure the people with the devryption key access do not have database access, and vice versa. ---------- Original Message ---------------------------------- From: "Charlotte Foust" Reply-To: dba-sqlserver at databaseadvisors.com Date: Wed, 11 May 2005 10:14:55 -0700 >Somehow, I think you're going to have to work out a compromise with >them. Could you promise not to peek, wear a blindfold when the table >is open, point out that they get a dba with the database, not one from >column A OR one from column B? > >Charlotte Foust > > >-----Original Message----- >From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] >Sent: Wednesday, May 11, 2005 8:31 AM >To: 'dba-sqlserver at databaseadvisors.com' >Subject: RE: [dba-SQLServer] Fwd: Security & encryption > > >I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fhtapia at gmail.com Wed May 11 16:20:32 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Wed, 11 May 2005 14:20:32 -0700 Subject: [dba-SQLServer] Audit Trails In-Reply-To: <0CC84C9461AE6445AD5A602001C41C4B05A2B0@mercury.tnco-inc.com> References: <0CC84C9461AE6445AD5A602001C41C4B05A2B0@mercury.tnco-inc.com> Message-ID: An effecient way is to create a trigger on table UPDATE. Using the trigger table "inserted" you can gain the newvalue you are seeking. On 5/11/05, Joe Rojas wrote: > > Hi All, > > How can I go about creating audit trails for a table in SS7.5? > > What I would like to be able to see is if a user updates a row I could > see: > EmpID > DateChanged > ColumnName > OldValue > NewValue > > Thanks! > JR > > This electronic transmission is strictly confidential to TNCO, Inc. and > intended solely for the addressee. It may contain information which is > covered by legal, professional, or other privileges. If you are not the > intended addressee, or someone authorized by the intended addressee to > receive transmissions on behalf of the addressee, you must not retain, > disclose in any form, copy, or take any action in reliance on this > transmission. If you have received this transmission in error, please > notify > the sender as soon as possible and destroy this message. While TNCO, Inc. > uses virus protection, the recipient should check this email and any > attachments for the presence of viruses. TNCO, Inc. accepts no liability > for > any damage caused by any virus transmitted by this email. > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From fhtapia at gmail.com Thu May 12 11:14:42 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Thu, 12 May 2005 09:14:42 -0700 Subject: [dba-SQLServer] Fwd: Security & encryption In-Reply-To: References: Message-ID: I found some additional information on encrypting tables and data for that matter, One article suggested to follow suit in the Label security that Oracle has laid out... http://www.oracle.com/technology//index.html Additionally this thread had some useful hints.. (duplicating relevant post) *Armstrong * *RE: Encryption with XP Crypt* Posted 2/11/2004 9:52:00 AM ** We are using xp_crypt to encrypt certain fields in our database. If you use this product and you want to "encrypt a particular table", you would do that by encrypting each field in the table separately. Because encryption and decryption take cpu time, I would suggest you encrypt only what is necessary. xp_crypt provides you with a .dll that provides you with some extended stored proceudres you can call from T-SQL. The parts of the product that I have used work as advertised. Technical support is by e-mail but is quite prompt. One of the issues that you will want to address early on is where to store your encryption keys. As you know, there are two basic types of encryption: *private key *and *public key*. Private key encryption uses the same key to both encrypt and decrypt. This makes it imperative that the key be kept secret, because anybody who has a copy of the key will be able to read your data. Because neither people nor computers are all that good at keeping secrets, some organizations even go so far as to place their private keys in hardware devices. The hardware device is designed to never reveal the key; rather you give it a string of data and the device does the encryption/decryption internally. This approach can provide very good security. One company which sells this kind of device is Rainbow Technologies (www.rainbow.com ). The devices work well but the implementation effort can be steep! (xp_crypt is MUCH simpler to use) Public key encryption uses a published key for encryption (the public key), and a different key for decryption (the private key). Public key encryption works well, is computationally intensive, and its encrypted data tends to take up a lot of space. We use it because it fits what we do: lots of people here need to encrypt data (order entry with credit card information), but only a few people need to decrypt (sending credit card info to the clearing house for payment). In other words, many people use a public key, but only a few use a private key so the key management is bearable. To sum up, we are using xp_crypt in a software-only solution because it was straightforward, not expensive, and was much better than storing sensitive information in the clear. However, hardware devices do provide better key management which helps security. Which one you choose would depend on your requirements and your budget. And of course more links re: rainbow http://www.safenet-inc.com/solutions/ent/HiSpeedEnc.asp?WT.MC_id=sol-hse00018 It also occured to me that there really are situations where data should remain encrypted such as banking info etc. Those databases SHOULD really be encrypted so that if they were hacked, the critical information would still remain safe. On 5/11/05, Charlotte Foust wrote: > > Certainly, but that ability to render the data meaningless or deny > access ALWAYS exists in the dba, regardless of whether the data is > encrypted. If you can't trust a dba or you won't trust one to protect > your interests and your data, then you should be keeping your data > someplace other than in a database. > > Charlotte Foust > > > -----Original Message----- > From: nicholas van [mailto:nick at frasiervan.com] > Sent: Wednesday, May 11, 2005 11:00 AM > To: dba-sqlserver at databaseadvisors.com > Subject: RE: [dba-SQLServer] Fwd: Security & encryption > > Mark has covered most of the main design points. > > As always, Higher Security = Greater Inconvenience > > I think it may be interesting to clarify what is meant by not letting > the sysadmins and DBA get into the data. Even if the data itself is > encrypted the DBA and System adminstrators will have the enough access > to seriously compromise the integrity of the data. Even if you cannot > know the exact data because it is encrypted, we are talking about people > who can effectively deny access to all others, or in other ways render > the data meaningless. > > As was pointed out with the encyption scheme, the most important point > of control is to make sure that the people who have access to the > encrypted data do not also have access to the encryption keys. Where we > are right now we deal with some confidential data and we make sure the > people with the devryption key access do not have database access, and > vice versa. > > ---------- Original Message ---------------------------------- > From: "Charlotte Foust" > Reply-To: dba-sqlserver at databaseadvisors.com > Date: Wed, 11 May 2005 10:14:55 -0700 > > >Somehow, I think you're going to have to work out a compromise with > >them. Could you promise not to peek, wear a blindfold when the table > >is open, point out that they get a dba with the database, not one from > >column A OR one from column B? > > > >Charlotte Foust > > > > > >-----Original Message----- > >From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] > >Sent: Wednesday, May 11, 2005 8:31 AM > >To: 'dba-sqlserver at databaseadvisors.com' > >Subject: RE: [dba-SQLServer] Fwd: Security & encryption > > > > > >I AM a DBA I can trust!!! But HR sadly don't feel the same way. :( > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From DElam at jenkens.com Fri May 13 09:42:00 2005 From: DElam at jenkens.com (Elam, Debbie) Date: Fri, 13 May 2005 09:42:00 -0500 Subject: [dba-SQLServer] Federated Databases Message-ID: <7B1961ED924D1A459E378C9B1BB22B4C02485E64@natexch.jenkens.com> Has anyone tried using Microsoft's SQL add in: federated databases? How stable is it? Any quirks? I have a customer asking about using it and I would like opinions on Microsoft. If there is a superior 3rd party product please let me know about it any why it is superior too. Here is Microsoft's site on federated databases: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ ar_cs_4fw3.asp Debbie - JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject to the Attorney-Client Privilege, (2) an attorney work product, or (3) strictly confidential. If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. This communication does not reflect an intention by the sender or the sender's client or principal to conduct a transaction or make any agreement by electronic means. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. From stuart at lexacorp.com.pg Fri May 13 17:54:07 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Sat, 14 May 2005 08:54:07 +1000 Subject: [dba-SQLServer] Federated Databases In-Reply-To: <7B1961ED924D1A459E378C9B1BB22B4C02485E64@natexch.jenkens.com> Message-ID: <4285BCAF.31418.19F23F48@stuart.lexacorp.com.pg> On 13 May 2005 at 9:42, Elam, Debbie wrote: > I have a customer asking about using it and I > would like opinions on Microsoft. That could provoke some vitriol :-) -- Stuart From stuart at lexacorp.com.pg Fri May 13 18:04:29 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Sat, 14 May 2005 09:04:29 +1000 Subject: [dba-SQLServer] Federated Databases In-Reply-To: <7B1961ED924D1A459E378C9B1BB22B4C02485E64@natexch.jenkens.com> Message-ID: <4285BF1D.11208.19FBBD94@stuart.lexacorp.com.pg> On 13 May 2005 at 9:42, Elam, Debbie wrote: > Has anyone tried using Microsoft's SQL add in: federated databases? How > stable is it? Any quirks? I have a customer asking about using it and I > would like opinions on Microsoft. If there is a superior 3rd party product > please let me know about it any why it is superior too. > Doesn't look like an add-in to me. It's just a technique for distribution your data over several servers. Follow the link on that page to "Partitioning data". It just seems like a long winded way for Microsoft to say that Views made up of UNION queries against identical tables in separate databases are updateable in SQL Server 2000. -- Stuart From cfoust at infostatsystems.com Fri May 13 19:27:49 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 13 May 2005 17:27:49 -0700 Subject: [dba-SQLServer] SP4 Message-ID: OK, I admit it. I am NOT a SQL Server person, even though I have to develop front ends against it. Can anyone explain SP4 and when, why and how it should be applied? The baseline security gizmo says I need it on my laptop. But I can't figure out how to apply it. I downloaded the several files, but I get stuff about sa not having a secure password. It does, it does, but I use Windows authentication! When I try to apply the analysis services version, I get un unenlightening error message and it aborts. Do I need this for anything? HELP!! Charlotte Foust Infostat Systems, Inc. From fhtapia at gmail.com Sat May 14 11:21:28 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Sat, 14 May 2005 09:21:28 -0700 Subject: [dba-SQLServer] SP4 In-Reply-To: References: Message-ID: I'm testing sp4 on my dev box right now, so far it seems to peform right on, but some of the features it brings such as improved #temp table handling I have not noticed mainly because my programming practice, which is, I explicitly create the #temp table first via Create Table #temp, and then populated rather than the lazy Select * into #temp From table it does have updated XML support which will come in handy in my new project, but I haven't gotten there yet. I think you want to patch SP4 first then follow up with the analysis pak but should you upgrade?.. list of bug fixes for sp4 http://support.microsoft.com/kb/888799/ list of bug fixes for sp4 (analysist pak) http://support.microsoft.com/kb/888800/ On 5/13/05, Charlotte Foust wrote: > > OK, I admit it. I am NOT a SQL Server person, even though I have to > develop front ends against it. Can anyone explain SP4 and when, why and > how it should be applied? The baseline security gizmo says I need it on > my laptop. But I can't figure out how to apply it. I downloaded the > several files, but I get stuff about sa not having a secure password. > It does, it does, but I use Windows authentication! When I try to apply > the analysis services version, I get un unenlightening error message and > it aborts. Do I need this for anything? HELP!! > > Charlotte Foust > Infostat Systems, Inc. > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From michael at ddisolutions.com.au Mon May 16 01:53:17 2005 From: michael at ddisolutions.com.au (Michael Maddison) Date: Mon, 16 May 2005 16:53:17 +1000 Subject: [dba-SQLServer] Federated Databases Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D010E4BE4@ddi-01.DDI.local> This is the last resort option, I've never had to really look at it. Are you sure the db server is the very best and it still can't cope with the web traffic? How many processors? How much RAM? How many HDD's? Speed? Has the DB been optimised? Where are the bottlenecks? More hardware is probably cheaper then redesigning the db... YMMV For an interesting discussion on high volume SQL http://discuss.joelonsoftware.com/default.asp?joel.3.126588.7 cheers Michael M On 13 May 2005 at 9:42, Elam, Debbie wrote: > Has anyone tried using Microsoft's SQL add in: federated databases? > How stable is it? Any quirks? I have a customer asking about using > it and I would like opinions on Microsoft. If there is a superior 3rd > party product please let me know about it any why it is superior too. > Doesn't look like an add-in to me. It's just a technique for distribution your data over several servers. Follow the link on that page to "Partitioning data". It just seems like a long winded way for Microsoft to say that Views made up of UNION queries against identical tables in separate databases are updateable in SQL Server 2000. -- Stuart _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From DElam at jenkens.com Mon May 16 13:25:22 2005 From: DElam at jenkens.com (Elam, Debbie) Date: Mon, 16 May 2005 13:25:22 -0500 Subject: [dba-SQLServer] Federated Databases Message-ID: <7B1961ED924D1A459E378C9B1BB22B4C02485E74@natexch.jenkens.com> The issue they really want dealt with is load ballancing. They also want a decent failover. The more info I am getting on federated databases says this is the wrong way to go to get what they want. I explored the issue though since they were very excited about the prospect, and I wanted to have concrete issues for or against. Since I had never heard of it being used, I wondered if it was stable too. Turns out it just has very limited utility that is often more easily solved with better hardware. Debbie -----Original Message----- From: Michael Maddison [mailto:michael at ddisolutions.com.au] Sent: Monday, May 16, 2005 1:53 AM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Federated Databases This is the last resort option, I've never had to really look at it. Are you sure the db server is the very best and it still can't cope with the web traffic? How many processors? How much RAM? How many HDD's? Speed? Has the DB been optimised? Where are the bottlenecks? More hardware is probably cheaper then redesigning the db... YMMV For an interesting discussion on high volume SQL http://discuss.joelonsoftware.com/default.asp?joel.3.126588.7 cheers Michael M On 13 May 2005 at 9:42, Elam, Debbie wrote: > Has anyone tried using Microsoft's SQL add in: federated databases? > How stable is it? Any quirks? I have a customer asking about using > it and I would like opinions on Microsoft. If there is a superior 3rd > party product please let me know about it any why it is superior too. > Doesn't look like an add-in to me. It's just a technique for distribution your data over several servers. Follow the link on that page to "Partitioning data". It just seems like a long winded way for Microsoft to say that Views made up of UNION queries against identical tables in separate databases are updateable in SQL Server 2000. -- Stuart _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com - JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject to the Attorney-Client Privilege, (2) an attorney work product, or (3) strictly confidential. If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. This communication does not reflect an intention by the sender or the sender's client or principal to conduct a transaction or make any agreement by electronic means. Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions. From artful at rogers.com Mon May 16 16:56:16 2005 From: artful at rogers.com (Arthur Fuller) Date: Mon, 16 May 2005 17:56:16 -0400 Subject: [dba-SQLServer] Insert a picture into a SQL column In-Reply-To: References: Message-ID: <42891700.2000307@rogers.com> Let's leave aside the wisdom of doing this and focus on the fact of doing it. I have a sproc that doesn't work. I pass a filename and the PK of the row into which I want to insert said image file. It doesn't work as written. I think that maybe I need to create a stream object and read chunks and then update the row using said accumulated chunk, but I cannot yet figure out how to do this in pure T-SQL. Suggestions? TIA, Arthur > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 From fhtapia at gmail.com Mon May 16 17:34:08 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Mon, 16 May 2005 15:34:08 -0700 Subject: [dba-SQLServer] Insert a picture into a SQL column In-Reply-To: <42891700.2000307@rogers.com> References: <42891700.2000307@rogers.com> Message-ID: Look in BOL under blob, here is a MS example on how to do what you want http://support.microsoft.com/kb/q173308/ I'm looking at a similar situation only because I'm going to need to display the same picture out on the web as in an internal app. Not sure if I'll use this approach due to the typical cautions. On 5/16/05, Arthur Fuller wrote: > > Let's leave aside the wisdom of doing this and focus on the fact of > doing it. I have a sproc that doesn't work. I pass a filename and the PK > of the row into which I want to insert said image file. It doesn't work > as written. I think that maybe I need to create a stream object and read > chunks and then update the row using said accumulated chunk, but I > cannot yet figure out how to do this in pure T-SQL. > > Suggestions? > > TIA, > Arthur > > > > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From artful at rogers.com Tue May 17 12:49:58 2005 From: artful at rogers.com (Arthur Fuller) Date: Tue, 17 May 2005 13:49:58 -0400 Subject: [dba-SQLServer] Insert a picture into a SQL column In-Reply-To: References: <42891700.2000307@rogers.com> Message-ID: <428A2EC6.9090801@rogers.com> That was interesting but not exactly where I want to go. If at all possible, I want to do it all in the SQL database, using a sproc that might resemble this: CREATE PROCEDURE ImageImport_ap ( @pk int, @imageFileName varchar(100) ) AS /* maybe I need a stream object or something here, I don't know but I want ideally to handle everything in the sproc, with no FE code but passing the parms */ UPDATE myTable SET Picture = [data read from image file] WHERE PK = @pk Anyone know how to achieve this? Arthur Francisco Tapia wrote: >Look in BOL under blob, >here is a MS example on how to do what you want > >http://support.microsoft.com/kb/q173308/ > >I'm looking at a similar situation only because I'm going to need to display >the same picture out on the web as in an internal app. Not sure if I'll use >this approach due to the typical cautions. > >On 5/16/05, Arthur Fuller wrote: > > >>Let's leave aside the wisdom of doing this and focus on the fact of >>doing it. I have a sproc that doesn't work. I pass a filename and the PK >>of the row into which I want to insert said image file. It doesn't work >>as written. I think that maybe I need to create a stream object and read >>chunks and then update the row using said accumulated chunk, but I >>cannot yet figure out how to do this in pure T-SQL. >> >>Suggestions? >> >>TIA, >>Arthur >> >> >> >>> >>> >>-- >>No virus found in this outgoing message. >>Checked by AVG Anti-Virus. >>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 >> >>_______________________________________________ >>dba-SQLServer mailing list >>dba-SQLServer at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>http://www.databaseadvisors.com >> >> >> >> > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 From Rich_Lavsa at pghcorning.com Tue May 17 15:04:06 2005 From: Rich_Lavsa at pghcorning.com (Lavsa, Rich) Date: Tue, 17 May 2005 16:04:06 -0400 Subject: [dba-SQLServer] Insert a picture into a SQL column Message-ID: <2A261FF9D5EBCA46940C11688CE872EE03AC88@goexchange2.pghcorning.com> Curiousity got me on this one so I did a little research. I found this page http://www.codecomments.com/archive352-2005-1-378799.html Of which contained this link http://support.microsoft.com/?kbid=258038 which is where I believe you are trying to go with the ADO Stream Object... As I don't currently have a use for this, I can see where it might fit in the near future so please let us know how you get it to work in the end.. Rich -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, May 17, 2005 1:50 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Insert a picture into a SQL column That was interesting but not exactly where I want to go. If at all possible, I want to do it all in the SQL database, using a sproc that might resemble this: CREATE PROCEDURE ImageImport_ap ( @pk int, @imageFileName varchar(100) ) AS /* maybe I need a stream object or something here, I don't know but I want ideally to handle everything in the sproc, with no FE code but passing the parms */ UPDATE myTable SET Picture = [data read from image file] WHERE PK = @pk Anyone know how to achieve this? Arthur Francisco Tapia wrote: >Look in BOL under blob, >here is a MS example on how to do what you want > >http://support.microsoft.com/kb/q173308/ > >I'm looking at a similar situation only because I'm going to need to >display >the same picture out on the web as in an internal app. Not sure if I'll use >this approach due to the typical cautions. > >On 5/16/05, Arthur Fuller wrote: > > >>Let's leave aside the wisdom of doing this and focus on the fact of >>doing it. I have a sproc that doesn't work. I pass a filename and the >>PK of the row into which I want to insert said image file. It doesn't >>work as written. I think that maybe I need to create a stream object >>and read chunks and then update the row using said accumulated chunk, >>but I cannot yet figure out how to do this in pure T-SQL. >> >>Suggestions? >> >>TIA, >>Arthur >> >> >> >>> >>> >>-- >>No virus found in this outgoing message. >>Checked by AVG Anti-Virus. >>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 >> >>_______________________________________________ >>dba-SQLServer mailing list >>dba-SQLServer at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>http://www.databaseadvisors.com >> >> >> >> > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From James at fcidms.com Tue May 17 15:27:55 2005 From: James at fcidms.com (James Barash) Date: Tue, 17 May 2005 16:27:55 -0400 Subject: [dba-SQLServer] Insert a picture into a SQL column In-Reply-To: <2A261FF9D5EBCA46940C11688CE872EE03AC88@goexchange2.pghcorning.com> Message-ID: <0IGN000AEI837B@mta1.srv.hcvlny.cv.net> Arthur: I think this article will give you what you are looking for. It's not very straightforward but if you are determined to do this in T-SQL, it does work. http://www.databasejournal.com/features/mssql/article.php/1443521 Just remember that filenames must be from the Server's point-of-view. Hope this helps. James Barash -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, May 17, 2005 1:50 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Insert a picture into a SQL column That was interesting but not exactly where I want to go. If at all possible, I want to do it all in the SQL database, using a sproc that might resemble this: CREATE PROCEDURE ImageImport_ap ( @pk int, @imageFileName varchar(100) ) AS /* maybe I need a stream object or something here, I don't know but I want ideally to handle everything in the sproc, with no FE code but passing the parms */ UPDATE myTable SET Picture = [data read from image file] WHERE PK = @pk Anyone know how to achieve this? Arthur Francisco Tapia wrote: >Look in BOL under blob, >here is a MS example on how to do what you want > >http://support.microsoft.com/kb/q173308/ > >I'm looking at a similar situation only because I'm going to need to >display >the same picture out on the web as in an internal app. Not sure if I'll use >this approach due to the typical cautions. > >On 5/16/05, Arthur Fuller wrote: > > >>Let's leave aside the wisdom of doing this and focus on the fact of >>doing it. I have a sproc that doesn't work. I pass a filename and the >>PK of the row into which I want to insert said image file. It doesn't >>work as written. I think that maybe I need to create a stream object >>and read chunks and then update the row using said accumulated chunk, >>but I cannot yet figure out how to do this in pure T-SQL. >> >>Suggestions? >> >>TIA, >>Arthur >> >> >> >>> >>> >>-- >>No virus found in this outgoing message. >>Checked by AVG Anti-Virus. >>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 >> >>_______________________________________________ >>dba-SQLServer mailing list >>dba-SQLServer at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>http://www.databaseadvisors.com >> >> >> >> > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From artful at rogers.com Tue May 17 20:28:01 2005 From: artful at rogers.com (Arthur Fuller) Date: Tue, 17 May 2005 21:28:01 -0400 Subject: [dba-SQLServer] Insert a picture into a SQL column In-Reply-To: <0IGN000AEI837B@mta1.srv.hcvlny.cv.net> References: <0IGN000AEI837B@mta1.srv.hcvlny.cv.net> Message-ID: <428A9A21.1050405@rogers.com> I had found that one myself, and hated the solution on two grounds: 1. way too many parameters, almost all of which would be assumed by the context... i.e. I could start with that code and rewrite it significantly. 2. the code reaches outside T-SQL to run textcopy, which subverts my original intent. I wanted to do the whole thing in T-SQL, and I'm concluding that it cannot be done. So my choices are to do it in the front-end using ADO or to pretend I'm doing it in the back end by running textcopy. Don't take this as a put-down of your proposed solution, or a slight upon your efforts to search for a solution for me. If there's a slam aimed anywhere, it's at Microsoft -- either for not providing the functionality I want or for providing it and not documenting it. And not only with image files! I would want this functionality with numerous file types, but let's take just a few simple cases that I might need -- extract the contents of a text file, extract the contents of a Word file, and so on. I might even want to inhale a .com or .exe file (can't think of a reason at the moment, but that's not the point) and store the contents in a file. I would want to declare a variable and manipulate it like so.... DECLARE @myVar AS mp3File SET @myVar = FileOpen( "MyFavouriteSong.mp3" UPDATE SongList SET Song = @myVar WHERE PK = 12345 But from everything I've read so far on this subject, it appears that I cannot do it in T-SQL. Why does this bug me so much? Because I believe that everything that can be done in the back end should be done in the back end. Then I wouldn't have to code the same stuff in several FE languages -- I could just have each FE language fire the sproc that does it all. Oh well. I live in a dream world. LOL. Arthur James Barash wrote: >Arthur: > >I think this article will give you what you are looking for. It's not very >straightforward but if you are determined to do this in T-SQL, it does work. > >http://www.databasejournal.com/features/mssql/article.php/1443521 > >Just remember that filenames must be from the Server's point-of-view. > >Hope this helps. > >James Barash > > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur >Fuller >Sent: Tuesday, May 17, 2005 1:50 PM >To: dba-sqlserver at databaseadvisors.com >Subject: Re: [dba-SQLServer] Insert a picture into a SQL column > > >That was interesting but not exactly where I want to go. If at all >possible, I want to do it all in the SQL database, using a sproc that >might resemble this: > >CREATE PROCEDURE ImageImport_ap >( > @pk int, > @imageFileName varchar(100) >) >AS > /* maybe I need a stream object or something here, I don't know > but I want ideally to handle everything in the sproc, with no FE >code but passing the parms > */ > UPDATE myTable > SET Picture = [data read from image file] > WHERE PK = @pk > >Anyone know how to achieve this? >Arthur > >Francisco Tapia wrote: > > > >>Look in BOL under blob, >>here is a MS example on how to do what you want >> >>http://support.microsoft.com/kb/q173308/ >> >>I'm looking at a similar situation only because I'm going to need to >>display >>the same picture out on the web as in an internal app. Not sure if I'll >> >> >use > > >>this approach due to the typical cautions. >> >>On 5/16/05, Arthur Fuller wrote: >> >> >> >> >>>Let's leave aside the wisdom of doing this and focus on the fact of >>>doing it. I have a sproc that doesn't work. I pass a filename and the >>>PK of the row into which I want to insert said image file. It doesn't >>>work as written. I think that maybe I need to create a stream object >>>and read chunks and then update the row using said accumulated chunk, >>>but I cannot yet figure out how to do this in pure T-SQL. >>> >>>Suggestions? >>> >>>TIA, >>>Arthur >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>-- >>>No virus found in this outgoing message. >>>Checked by AVG Anti-Virus. >>>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 >>> >>>_______________________________________________ >>>dba-SQLServer mailing list >>>dba-SQLServer at databaseadvisors.com >>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>>http://www.databaseadvisors.com >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 From James at fcidms.com Wed May 18 09:18:05 2005 From: James at fcidms.com (James Barash) Date: Wed, 18 May 2005 10:18:05 -0400 Subject: [dba-SQLServer] Insert a picture into a SQL column In-Reply-To: <428A9A21.1050405@rogers.com> Message-ID: <0IGO00BKFVQHNQ@mta7.srv.hcvlny.cv.net> I agree, it's not a great solution -- I didn't like it any more than you do -- but the only one I found when I tried to do something similar. If you can wait for SQL 2005, you'll be able to write stored procedures in the .Net language of your choice and then the solution becomes easy, although no longer T-SQL. James Barash -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, May 17, 2005 9:28 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Insert a picture into a SQL column I had found that one myself, and hated the solution on two grounds: 1. way too many parameters, almost all of which would be assumed by the context... i.e. I could start with that code and rewrite it significantly. 2. the code reaches outside T-SQL to run textcopy, which subverts my original intent. I wanted to do the whole thing in T-SQL, and I'm concluding that it cannot be done. So my choices are to do it in the front-end using ADO or to pretend I'm doing it in the back end by running textcopy. Don't take this as a put-down of your proposed solution, or a slight upon your efforts to search for a solution for me. If there's a slam aimed anywhere, it's at Microsoft -- either for not providing the functionality I want or for providing it and not documenting it. And not only with image files! I would want this functionality with numerous file types, but let's take just a few simple cases that I might need -- extract the contents of a text file, extract the contents of a Word file, and so on. I might even want to inhale a .com or .exe file (can't think of a reason at the moment, but that's not the point) and store the contents in a file. I would want to declare a variable and manipulate it like so.... DECLARE @myVar AS mp3File SET @myVar = FileOpen( "MyFavouriteSong.mp3" UPDATE SongList SET Song = @myVar WHERE PK = 12345 But from everything I've read so far on this subject, it appears that I cannot do it in T-SQL. Why does this bug me so much? Because I believe that everything that can be done in the back end should be done in the back end. Then I wouldn't have to code the same stuff in several FE languages -- I could just have each FE language fire the sproc that does it all. Oh well. I live in a dream world. LOL. Arthur James Barash wrote: >Arthur: > >I think this article will give you what you are looking for. It's not very >straightforward but if you are determined to do this in T-SQL, it does work. > >http://www.databasejournal.com/features/mssql/article.php/1443521 > >Just remember that filenames must be from the Server's point-of-view. > >Hope this helps. > >James Barash > > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur >Fuller >Sent: Tuesday, May 17, 2005 1:50 PM >To: dba-sqlserver at databaseadvisors.com >Subject: Re: [dba-SQLServer] Insert a picture into a SQL column > > >That was interesting but not exactly where I want to go. If at all >possible, I want to do it all in the SQL database, using a sproc that >might resemble this: > >CREATE PROCEDURE ImageImport_ap >( > @pk int, > @imageFileName varchar(100) >) >AS > /* maybe I need a stream object or something here, I don't know > but I want ideally to handle everything in the sproc, with no FE >code but passing the parms > */ > UPDATE myTable > SET Picture = [data read from image file] > WHERE PK = @pk > >Anyone know how to achieve this? >Arthur > >Francisco Tapia wrote: > > > >>Look in BOL under blob, >>here is a MS example on how to do what you want >> >>http://support.microsoft.com/kb/q173308/ >> >>I'm looking at a similar situation only because I'm going to need to >>display >>the same picture out on the web as in an internal app. Not sure if I'll >> >> >use > > >>this approach due to the typical cautions. >> >>On 5/16/05, Arthur Fuller wrote: >> >> >> >> >>>Let's leave aside the wisdom of doing this and focus on the fact of >>>doing it. I have a sproc that doesn't work. I pass a filename and the >>>PK of the row into which I want to insert said image file. It doesn't >>>work as written. I think that maybe I need to create a stream object >>>and read chunks and then update the row using said accumulated chunk, >>>but I cannot yet figure out how to do this in pure T-SQL. >>> >>>Suggestions? >>> >>>TIA, >>>Arthur >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>-- >>>No virus found in this outgoing message. >>>Checked by AVG Anti-Virus. >>>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 >>> >>>_______________________________________________ >>>dba-SQLServer mailing list >>>dba-SQLServer at databaseadvisors.com >>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >>>http://www.databaseadvisors.com >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005 _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From John.Maxwell2 at ntl.com Wed May 18 13:55:07 2005 From: John.Maxwell2 at ntl.com (John Maxwell @ London City) Date: Wed, 18 May 2005 19:55:07 +0100 Subject: [dba-SQLServer] 'Just Date' criteria. Message-ID: <9139E3F4E672964A97149F0F2113E68115ED0B@mast-ln0-se01.private.ntl.com> Hello all, apologies if basic question but your help is appreciated. Issue / Problem: I need to select data with a particular date value but ignore the time contained in the data. ie all records from a particular day what ever the time I can see a number of solutions eg. * Convert date (Guess not always good solution as may not use available indexes) * Use range in criteria (Is this efficient) * Use multiple date part functions (Is this efficient and any different from point above) Any views / advice on what is usually the most efficient method would be great Thanks in advance john The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited From Rich_Lavsa at pghcorning.com Thu May 19 13:02:15 2005 From: Rich_Lavsa at pghcorning.com (Lavsa, Rich) Date: Thu, 19 May 2005 14:02:15 -0400 Subject: [dba-SQLServer] Use one field or another in query based on a condition Message-ID: <2A261FF9D5EBCA46940C11688CE872EE03AC8E@goexchange2.pghcorning.com> Hello all, I came from an Access world, and so far have been mostly self taught on the SQL Server side of things. One thing that I used to do in Access from time to time is have 2 fields that were returned in a query, however for reporting purposes, sometimes it was determined that one or the other was to be used depending on a condition. This was easy in Access as it allowed you to use an IIF() statement and actually use the value of another field inline with each record. Now I'm trying to do the same in the following query in SQL Server. In the Middle of the Select portion, you will see CustomerAddress.Sys_address_1 and at the end you will see NoOrderAddress.Address1 AS NoOrdAdd1. What can happen in this scenario is that sometimes the information is brought back from our ERP system in which the Order Number will return all the pertant information, however in very few cases I had to allow the entry of data even though there wasn't an Order number to refer to, so the information on a NO ORDER would be manually entered. So what I hope to achieve is to return the value CustomerAddress.Sys_address_1 if RGA.PCCOrderNo <> 'No Order' else return NoOrderAddress.Address1 AS NoOrdAdd1. I tried the ISNULL approach, Case statement, and an IF statement neither of which worked in returning a value that is inline, however all worked in testing for the condition and returning text but none acutally returned the field value when I ask it to return NoOrderAddress.Address1. Any help would be greatly appreciated. SELECT RGA.RGANo, RGA.RGADate, RGA.ContactFName, RGA.ContactlName, isnull(RGA.ContactFName,'') + ' ' + isnull(RGA.ContactlName,'') as ContactName, CustomerAddress.CUSTOMER_NAME AS CompanyName, RGA.PCCOrderNo, UsedOrderInfo.CUSTOMER_REFERENCE AS CustomerRef, RGA.Freight, CASE rga.restockfee when 0 then 'No' when 1 then 'Yes' else 'N/A' End as Restockfee, RGA.RGANotes, RGA.FreightStatus, PCCRep.FirstName, PCCRep.LastName, lkpReason.ReasonDesc, lkpWarehouse.Companyname as whseCompanyName, lkpWarehouse.Address1 as whseAddress1, lkpWarehouse.Address2 as whseAddress2, lkpWarehouse.City as whseCity, lkpWarehouse.State as whseState, lkpWarehouse.Zip as whseZip, RGA.RGAId, dbo.NoOrderAddress.Address1 AS NoOrdAdd1, CustomerAddress.SYS_ADDRESS_1, CustomerAddress.SYS_ADDRESS_2, CustomerAddress.SYS_POSTAL_CODE, CustomerAddress.SYS_CITY, CustomerAddress.SYS_STATE, UsedOrderInfo.CUSTOMER_NUMBER AS CompanyNumber, lkpWarehouse.Location, RGA.ReasonForCredit, RGA.DetailsOfCredit, RGA.Approved, UsedOrderInfo.DELIVERY_ADDRESS_CODE, UsedOrderInfo.INVOICE_ADDRESS_CODE, CustomerAddress.ADDRESS_CODE, RGA.RequestedCredit, lkpStatus.StatusDesc, NoOrderAddress.CompanyName AS NoOrdCoName, NoOrderAddress.Address1 AS NoOrdAdd1, NoOrderAddress.Address2 AS NoOrdAdd2, NoOrderAddress.City AS NoOrdCity, NoOrderAddress.State AS NoOrdState, NoOrderAddress.ZipCode AS NoOrdZip, NoOrderAddress.PhoneNumber AS NoOrdPhone, NoOrderAddress.FaxNumber AS NoOrdFax, NoOrderAddress.DiscrepancyNotes AS NoOrdNotes FROM dbo.lkpReason RIGHT OUTER JOIN dbo.lkpWarehouse RIGHT OUTER JOIN dbo.PCCRep RIGHT OUTER JOIN dbo.NoOrderAddress RIGHT OUTER JOIN dbo.RGA ON dbo.NoOrderAddress.RGAID = dbo.RGA.RGAId ON dbo.PCCRep.PCCRepID = dbo.RGA.PCCRepID ON dbo.lkpWarehouse.WarehouseID = dbo.RGA.WarehouseID ON dbo.lkpReason.reasonID = dbo.RGA.ReasonID LEFT OUTER JOIN dbo.UsedOrderInfo LEFT OUTER JOIN OPENQUERY(RENCS, 'select Address_code, Customer_number, sys_Postal_code, Customer_Name, sys_address_1, sys_address_2, sys_state, sys_city from fin_prod.CUSTOMER_ADDRESSES') CustomerAddress ON dbo.UsedOrderInfo.DELIVERY_ADDRESS_CODE = CustomerAddress.ADDRESS_CODE AND dbo.UsedOrderInfo.CUSTOMER_NUMBER = CustomerAddress.CUSTOMER_NUMBER ON dbo.RGA.PCCOrderNo = dbo.UsedOrderInfo.ORDER_NUMBER LEFT OUTER JOIN dbo.lkpStatus ON dbo.RGA.RGAStatus = dbo.lkpStatus.StatusID Where RGA.PCCOrderNo = 'No Order' Rich From fhtapia at gmail.com Thu May 19 13:20:33 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Thu, 19 May 2005 11:20:33 -0700 Subject: [dba-SQLServer] Use one field or another in query based on a condition In-Reply-To: <2A261FF9D5EBCA46940C11688CE872EE03AC8E@goexchange2.pghcorning.com> References: <2A261FF9D5EBCA46940C11688CE872EE03AC8E@goexchange2.pghcorning.com> Message-ID: Try including the following Case statement... if the PCCOrderNO = No Order then the NoOrder address will be displayed, otherwise the Order one will. CASE RGA.PCCOrderNo = 'No Order' THEN NoOrderAddress.Address1 ELSE CustomerAddress.Sys_address_1 END AS NoOrdAdd1, On 5/19/05, Lavsa, Rich wrote: > > > In the Middle of the Select portion, you will see > CustomerAddress.Sys_address_1 and at the end you will see > NoOrderAddress.Address1 AS NoOrdAdd1. What can happen in this scenario > is that sometimes the information is brought back from our ERP system in > which the Order Number will return all the pertant information, however > in very few cases I had to allow the entry of data even though there > wasn't an Order number to refer to, so the information on a NO ORDER > would be manually entered. So what I hope to achieve is to return the > value CustomerAddress.Sys_address_1 if RGA.PCCOrderNo <> 'No Order' else > return NoOrderAddress.Address1 AS NoOrdAdd1. I tried the ISNULL > approach, Case statement, and an IF statement neither of which worked in > returning a value that is inline, however all worked in testing for the > condition and returning text but none acutally returned the field value > when I ask it to return NoOrderAddress.Address1. > > Any help would be greatly appreciated. > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From DavidL at sierranevada.com Thu May 19 13:24:24 2005 From: DavidL at sierranevada.com (David Lewis) Date: Thu, 19 May 2005 11:24:24 -0700 Subject: [dba-SQLServer] RE: Just Date Message-ID: <9ECA50D4E155CB40BB379B4DF0ADB14803F53D@exchange-02.sierranevada.corp> I find the following works well: CONVERT(DATETIME,(CONVERT(varchar,TheDateField,112))) This strips off the time portion and returns the date. I have never perceived any performance hits, but I also haven't done any rigorous comparisons. HTH D. Lewis From tuxedo_man at hotmail.com Thu May 19 16:35:03 2005 From: tuxedo_man at hotmail.com (Billy Pang) Date: Thu, 19 May 2005 21:35:03 +0000 Subject: [dba-SQLServer] 'Just Date' criteria. In-Reply-To: <9139E3F4E672964A97149F0F2113E68115ED0B@mast-ln0-se01.private.ntl.com> Message-ID: Hi John: I'd probably use a date range. For example, in northwind database, if i want to look for all orders with order date on July 8, 1996, I'd use: select orderid, OrderDate from orders where orderdate >= '7/8/1996' and orderdate < '7/9/1996'; or... select orderid, OrderDate from orders where orderdate >= convert(smalldatetime,'07/08/1996',101) and orderdate < convert(smalldatetime,'07/09/1996',101); the second select statement is "international date friendly" because it uses the convert function to explicity define whether the "7" is the day or the month. They both have idential execution plan (except that the first one has to convert the text strings (eg. '7/8/1996') into the datetime datatype before querying data. If I go with the datepart method, it would look something like this: select orderid, OrderDate from orders where month(orderdate) = 7 and day(orderdate) = 8 and year(orderdate) = 1996; In this example, in my opinion, it is a little bit more harder to read than the first two. Also, it does not use the indexes efficiently because index scan is required to get the partial date matches. In the first two examples, index seeks were performed. Index seeks are better than index scans. Billy >From: "John Maxwell @ London City" >Reply-To: dba-sqlserver at databaseadvisors.com >To: "'dba-sqlserver at databaseadvisors.com'" > >Subject: [dba-SQLServer] 'Just Date' criteria. >Date: Wed, 18 May 2005 19:55:07 +0100 > >Hello all, > >apologies if basic question but your help is appreciated. > >Issue / Problem: >I need to select data with a particular date value >but ignore the time contained in the data. >ie all records from a particular day what ever the time > >I can see a number of solutions eg. >* Convert date (Guess not always good solution as may not use >available indexes) >* Use range in criteria (Is this efficient) >* Use multiple date part functions (Is this efficient and any >different from point above) > >Any views / advice on what is usually the most efficient method would be >great > >Thanks in advance > >john > > >The contents of this email and any attachments are sent for the personal >attention >of the addressee(s) only and may be confidential. If you are not the >intended >addressee, any use, disclosure or copying of this email and any attachments >is >unauthorised - please notify the sender by return and delete the message. >Any >representations or commitments expressed in this email are subject to >contract. > >ntl Group Limited > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > From John.Maxwell2 at ntl.com Thu May 19 20:46:10 2005 From: John.Maxwell2 at ntl.com (John Maxwell @ London City) Date: Fri, 20 May 2005 02:46:10 +0100 Subject: [dba-SQLServer] 'Just Date' criteria. Message-ID: <9139E3F4E672964A97149F0F2113E68115ED23@mast-ln0-se01.private.ntl.com> Billy / David firstly thanks for responses - as always help of group appreciated. have gone with using date range also you have answered my query in that wrapping the date criteria in convert function does not stop the index seek. (I was considering using the convert in the select element of statement as getdate() for criteria, think this may stop the index seek) Thanks again. Regards john -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Billy Pang Sent: 19 May 2005 22:35 To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] 'Just Date' criteria. Hi John: I'd probably use a date range. For example, in northwind database, if i want to look for all orders with order date on July 8, 1996, I'd use: select orderid, OrderDate from orders where orderdate >= '7/8/1996' and orderdate < '7/9/1996'; or... select orderid, OrderDate from orders where orderdate >= convert(smalldatetime,'07/08/1996',101) and orderdate < convert(smalldatetime,'07/09/1996',101); the second select statement is "international date friendly" because it uses the convert function to explicity define whether the "7" is the day or the month. They both have idential execution plan (except that the first one has to convert the text strings (eg. '7/8/1996') into the datetime datatype before querying data. If I go with the datepart method, it would look something like this: select orderid, OrderDate from orders where month(orderdate) = 7 and day(orderdate) = 8 and year(orderdate) = 1996; In this example, in my opinion, it is a little bit more harder to read than the first two. Also, it does not use the indexes efficiently because index scan is required to get the partial date matches. In the first two examples, index seeks were performed. Index seeks are better than index scans. Billy >From: "John Maxwell @ London City" >Reply-To: dba-sqlserver at databaseadvisors.com >To: "'dba-sqlserver at databaseadvisors.com'" > >Subject: [dba-SQLServer] 'Just Date' criteria. >Date: Wed, 18 May 2005 19:55:07 +0100 > >Hello all, > >apologies if basic question but your help is appreciated. > >Issue / Problem: >I need to select data with a particular date value >but ignore the time contained in the data. >ie all records from a particular day what ever the time > >I can see a number of solutions eg. >* Convert date (Guess not always good solution as may not use >available indexes) >* Use range in criteria (Is this efficient) >* Use multiple date part functions (Is this efficient and any >different from point above) > >Any views / advice on what is usually the most efficient method would be >great > >Thanks in advance > >john > > >The contents of this email and any attachments are sent for the personal >attention >of the addressee(s) only and may be confidential. If you are not the >intended >addressee, any use, disclosure or copying of this email and any attachments >is >unauthorised - please notify the sender by return and delete the message. >Any >representations or commitments expressed in this email are subject to >contract. > >ntl Group Limited > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited From Rich_Lavsa at pghcorning.com Fri May 20 07:28:44 2005 From: Rich_Lavsa at pghcorning.com (Lavsa, Rich) Date: Fri, 20 May 2005 08:28:44 -0400 Subject: [dba-SQLServer] Use one field or another in query based on acondition Message-ID: <2A261FF9D5EBCA46940C11688CE872EE03AC8F@goexchange2.pghcorning.com> I had already tried the exact case statement you gave prior to my post and I swear to the gods above that it did not work.. And today.. Well it works perfectly. Maybe I had a typo or something.. Who knows.. Just to be correct in the post a Case statement uses When not an = .. CASE RGA.PCCOrderNo WHEN 'No Order' THEN NoOrderAddress.Address1 ELSE CustomerAddress.Sys_address_1 END AS NoOrdAdd1 Thanks for your response Francisco Rich -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia Sent: Thursday, May 19, 2005 2:21 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Use one field or another in query based on acondition Try including the following Case statement... if the PCCOrderNO = No Order then the NoOrder address will be displayed, otherwise the Order one will. CASE RGA.PCCOrderNo = 'No Order' THEN NoOrderAddress.Address1 ELSE CustomerAddress.Sys_address_1 END AS NoOrdAdd1, On 5/19/05, Lavsa, Rich wrote: > > > In the Middle of the Select portion, you will see > CustomerAddress.Sys_address_1 and at the end you will see > NoOrderAddress.Address1 AS NoOrdAdd1. What can happen in this scenario > is that sometimes the information is brought back from our ERP system > in which the Order Number will return all the pertant information, > however in very few cases I had to allow the entry of data even though > there wasn't an Order number to refer to, so the information on a NO > ORDER would be manually entered. So what I hope to achieve is to > return the value CustomerAddress.Sys_address_1 if RGA.PCCOrderNo <> > 'No Order' else return NoOrderAddress.Address1 AS NoOrdAdd1. I tried > the ISNULL approach, Case statement, and an IF statement neither of > which worked in returning a value that is inline, however all worked > in testing for the condition and returning text but none acutally > returned the field value when I ask it to return > NoOrderAddress.Address1. > > Any help would be greatly appreciated. > > -- -Francisco From listmaster at databaseadvisors.com Fri May 20 16:31:15 2005 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Fri, 20 May 2005 17:31:15 -0400 Subject: [dba-SQLServer] Administrivia - Emergency Server Repair Message-ID: <428E1EE3.9260.B9793E@localhost> I just got a notice from the host that hosts our mail server that they have had a HD failure. They will be taking our server down from 0900 - 1200 CST (14:00 - 17:00:00 UTC) tomorrow, Sat May 21, to replace the HD and upgrade the RAID software. Sorry for any inconveniance this may cause anyone. Bryan From Paul.Hartland at orridge.co.uk Thu May 26 07:30:44 2005 From: Paul.Hartland at orridge.co.uk (Paul Hartland) Date: Thu, 26 May 2005 13:30:44 +0100 Subject: [dba-SQLServer] Truncate Log On Checkpoint Message-ID: <14A7AB003EFD444BBB193A23128DA20E264E54@AL-PRI.Aldridge.local> To all, I want to be able to turn on the following option in a SQL Server 2000 database - trunc. log on chkpt but can't for the life of me see where I do this, I am quite new to SQL Server and have never used this option before but think it will be quite useful. Can anyone help me on this..... Thanks in advance for any help..... PAUL HARTLAND Database Designer/Programmer paul.hartland at isharp.co.uk West Midlands England ISHARP DDI - 01922 472031 Mobile - 07730 523179 _______________________________________________ * This message is confidential. * This email, its content and any files transmitted with it are intended solely for the addressee and may be legally privileged and/or confidential. * Access by any other party is unauthorised without the express written permission of the sender. * If you have received this email in error you may not copy or use the contents, attachments or information in any way and any review, use, dissemination, forwarding, disclosure, alteration, printing of this information is strictly prohibited. Please destroy it and notify the sender via return e-mail. * This email has been prepared using information believed by Paul Hartland to be reliable and accurate, but the company makes no warranty as to accuracy or completeness. In particular the author does not accept responsibility for changes made to this email after it was sent. * Any opinions expressed in this document are those of the author and do not necessarily reflect the opinions of the company or its affiliates. The Orridge web site can be found at: http://www.orridge.co.uk From ssharkins at bellsouth.net Thu May 26 07:53:43 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Thu, 26 May 2005 08:53:43 -0400 Subject: [dba-SQLServer] FW: FW: Element K Journal article Message-ID: <20050526125346.CYPB24612.ibm63aec.bellsouth.net@SUSANONE> The following came from a reader -- the reader is trying to adapt an Access technique for SQL Server. Gustav was the technical end of this article and his initial suggestion was to omit the AS keyword, but that didn't work. Anybody else want to offer a suggestion? Hi Susan, I read with interest your articles each month that appear in Inside Microsoft Access. Although I have been doing advanced programming in Access for about 10 years, each month I learn a new trick or two. Most of the time it's from one of your articles. I just finished reading "Retrieve data from a text file without attaching to or importing the file". I tried your examples and they work as listed. I am actually trying to do the exact same thing in SQL Server 2000 and also SQL Server CE. I tried using the same examples that I used in Access but on the SQL IN clause select * from Test#csv] as t in '' [Text;DATABASE=E:\] I get this error message. "Incorrect syntax near the keyword 'in'." In the IN-Less clause, select * from [Text;DATABASE=E:\Test.csv] as t I get this error message. "Invalid object name 'Text;DATABASE=E:\Test.csv'." Is there a similar syntax that works in SQL Server? Thanks, Fred From fhtapia at gmail.com Thu May 26 11:04:48 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Thu, 26 May 2005 09:04:48 -0700 Subject: [dba-SQLServer] Truncate Log On Checkpoint In-Reply-To: <14A7AB003EFD444BBB193A23128DA20E264E54@AL-PRI.Aldridge.local> References: <14A7AB003EFD444BBB193A23128DA20E264E54@AL-PRI.Aldridge.local> Message-ID: The Transaction Log will automatically truncate after a backup...the best way to do this rather than the checkpoint is to schedule a transaction log backup at an interval that is fair for you. When your recovery model is set to full you can then restore up to the minute before failure. On 5/26/05, Paul Hartland wrote: > To all, > > I want to be able to turn on the following option in a SQL > Server 2000 database - trunc. log on chkpt > but can't for the life of me see where I do this, I am quite new > to SQL Server and have never used this option before but think it will > be quite useful. > > Can anyone help me on this..... > > Thanks in advance for any help..... > > > PAUL HARTLAND > Database Designer/Programmer > paul.hartland at isharp.co.uk > West Midlands > England > ISHARP > DDI - 01922 472031 > Mobile - 07730 523179 > > > > _______________________________________________ > > * This message is confidential. > * This email, its content and any files transmitted with it are intended solely for the addressee and may be legally privileged and/or confidential. > * Access by any other party is unauthorised without the express written permission of the sender. > * If you have received this email in error you may not copy or use the contents, attachments or information in any way and any review, use, dissemination, forwarding, disclosure, alteration, printing of this information is strictly prohibited. Please destroy it and notify the sender via return e-mail. > * This email has been prepared using information believed by Paul Hartland to be reliable and accurate, but the company makes no warranty as to accuracy or completeness. In particular the author does not accept responsibility for changes made to this email after it was sent. > * Any opinions expressed in this document are those of the author and do not necessarily reflect the opinions of the company or its affiliates. > > The Orridge web site can be found at: > http://www.orridge.co.uk > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From tuxedo_man at hotmail.com Thu May 26 15:11:39 2005 From: tuxedo_man at hotmail.com (Billy Pang) Date: Thu, 26 May 2005 20:11:39 +0000 Subject: [dba-SQLServer] FW: FW: Element K Journal article In-Reply-To: <20050526125346.CYPB24612.ibm63aec.bellsouth.net@SUSANONE> Message-ID: someone correct me if i am wrong but I don't think it is possible to use a text file as the source for a select statement directly. you have to use the bulk insert statement to insert into a table and then display it from there. for example, i export the customers table in northwind database to a local csv file (with the header row and trailing row count stripped out, the file should only contain 91 records): /* -- cut here -- */ use tempdb go set nocount on go CREATE TABLE [Customers] ( [CustomerID] [nchar] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [CompanyName] [nvarchar] (40) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [ContactName] [nvarchar] (30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [ContactTitle] [nvarchar] (30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Address] [nvarchar] (60) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [City] [nvarchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Region] [nvarchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [PostalCode] [nvarchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Country] [nvarchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Phone] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , [Fax] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , CONSTRAINT [PK_Customers] PRIMARY KEY CLUSTERED ( [CustomerID] ) ON [PRIMARY] ) ON [PRIMARY] GO BULK INSERT tempdb..Customers FROM 'c:\test.csv' WITH ( FIELDTERMINATOR = '\t', ROWTERMINATOR = '\n' ) go select * from customers; go drop table customers go /* -- cut here -- */ HTH Billy >From: "Susan Harkins" >Reply-To: dba-sqlserver at databaseadvisors.com >To: >Subject: [dba-SQLServer] FW: FW: Element K Journal article >Date: Thu, 26 May 2005 08:53:43 -0400 > >The following came from a reader -- the reader is trying to adapt an Access >technique for SQL Server. Gustav was the technical end of this article and >his initial suggestion was to omit the AS keyword, but that didn't work. > >Anybody else want to offer a suggestion? > > >Hi Susan, > >I read with interest your articles each month that appear in Inside >Microsoft Access. Although I have been doing advanced programming in >Access >for about 10 years, each month I learn a new trick or two. Most of the >time >it's from one of your articles. I just finished reading "Retrieve data >from >a text file without attaching to or importing the file". I tried your >examples and they work as listed. I am actually trying to do the exact >same >thing in SQL Server 2000 and also SQL Server CE. I tried using the same >examples that I used in Access but on the SQL IN clause > >select * from Test#csv] as t in '' [Text;DATABASE=E:\] > > > >I get this error message. > >"Incorrect syntax near the keyword 'in'." > > > >In the IN-Less clause, > >select * from [Text;DATABASE=E:\Test.csv] as t > > > >I get this error message. > >"Invalid object name 'Text;DATABASE=E:\Test.csv'." > > > > Is there a similar syntax that works in SQL Server? > > > >Thanks, > > > >Fred > > > > > > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > From stuart at lexacorp.com.pg Thu May 26 17:23:15 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Fri, 27 May 2005 08:23:15 +1000 Subject: [dba-SQLServer] FW: FW: Element K Journal article In-Reply-To: <20050526125346.CYPB24612.ibm63aec.bellsouth.net@SUSANONE> Message-ID: <4296D8F3.3686.A2A55D0@stuart.lexacorp.com.pg> On 26 May 2005 at 8:53, Susan Harkins wrote: > The following came from a reader -- the reader is trying to adapt an Access > technique for SQL Server. Gustav was the technical end of this article and > his initial suggestion was to omit the AS keyword, but that didn't work. > > > select * from Test#csv] as t in '' [Text;DATABASE=E:\] > I don't think you can do it without defining the text file as a "linked server" first. Here's an example for sp_addlinkedserver in BOL: I. Use the Microsoft OLE DB Provider for Jet to access a text file This example creates a linked server for directly accessing text files, without linking the files as tables in an Access .mdb file. The provider is Microsoft.Jet.OLEDB.4.0 and the provider string is 'Text'. The data source is the full pathname of the directory that contains the text files. A schema.ini file, which describes the structure of the text files, must exist in the same directory as the text files. Refer to the Jet documentation for information about creating a schema.ini file. --Create a linked server EXEC sp_addlinkedserver txtsrv, 'Jet 4.0', 'Microsoft.Jet.OLEDB.4.0', 'c:\data\distqry', NULL, 'Text' GO --Set up login mappings EXEC sp_addlinkedsrvlogin txtsrv, FALSE, Admin, NULL GO --List the tables in the linked server EXEC sp_tables_ex txtsrv GO --Query one of the tables: file1#txt --using a 4-part name SELECT * FROM txtsrv...[file1#txt] -- Stuart From ssharkins at bellsouth.net Thu May 26 17:26:38 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Thu, 26 May 2005 18:26:38 -0400 Subject: [dba-SQLServer] FW: FW: Element K Journal article In-Reply-To: <4296D8F3.3686.A2A55D0@stuart.lexacorp.com.pg> Message-ID: <20050526222639.GRWA25991.ibm58aec.bellsouth.net@SUSANONE> OH my gosh.. That gives me SUCH a headache... But thank you -- I'll pass this along. :) Susan H. On 26 May 2005 at 8:53, Susan Harkins wrote: > The following came from a reader -- the reader is trying to adapt an > Access technique for SQL Server. Gustav was the technical end of this > article and his initial suggestion was to omit the AS keyword, but that didn't work. > > > select * from Test#csv] as t in '' [Text;DATABASE=E:\] > I don't think you can do it without defining the text file as a "linked server" first. Here's an example for sp_addlinkedserver in BOL: I. Use the Microsoft OLE DB Provider for Jet to access a text file This example creates a linked server for directly accessing text files, without linking the files as tables in an Access .mdb file. The provider is Microsoft.Jet.OLEDB.4.0 and the provider string is 'Text'. The data source is the full pathname of the directory that contains the text files. A schema.ini file, which describes the structure of the text files, must exist in the same directory as the text files. Refer to the Jet documentation for information about creating a schema.ini file. --Create a linked server EXEC sp_addlinkedserver txtsrv, 'Jet 4.0', 'Microsoft.Jet.OLEDB.4.0', 'c:\data\distqry', NULL, 'Text' GO --Set up login mappings EXEC sp_addlinkedsrvlogin txtsrv, FALSE, Admin, NULL GO --List the tables in the linked server EXEC sp_tables_ex txtsrv GO --Query one of the tables: file1#txt --using a 4-part name SELECT * FROM txtsrv...[file1#txt] -- Stuart _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From Paul.Hartland at orridge.co.uk Fri May 27 02:11:10 2005 From: Paul.Hartland at orridge.co.uk (Paul Hartland) Date: Fri, 27 May 2005 08:11:10 +0100 Subject: [dba-SQLServer] Truncate Log On Checkpoint Message-ID: <14A7AB003EFD444BBB193A23128DA20E264E92@AL-PRI.Aldridge.local> I have two files in my directory Genesis_Data.MDF Genesis_Log.LDF Genesis_Log.LDF is ever increasing and doesn't shrink, is there something wrong with the file or should I be truncating this manually PAUL HARTLAND Database Designer/Programmer paul.hartland at isharp.co.uk ISHARP DDI - 01922 472031 Mobile - 07730 523179 ISHARP (Information Services for Hospitality, Audit, Retail and Pharmacy) provide IT resources for the Christie Group Stock & Inventory Services companies. -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia Sent: 26 May 2005 17:05 To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Truncate Log On Checkpoint The Transaction Log will automatically truncate after a backup...the best way to do this rather than the checkpoint is to schedule a transaction log backup at an interval that is fair for you. When your recovery model is set to full you can then restore up to the minute before failure. On 5/26/05, Paul Hartland wrote: > To all, > > I want to be able to turn on the following option in a SQL > Server 2000 database - trunc. log on chkpt > but can't for the life of me see where I do this, I am quite > new to SQL Server and have never used this option before but think it > will be quite useful. > > Can anyone help me on this..... > > Thanks in advance for any help..... > > > PAUL HARTLAND > Database Designer/Programmer > paul.hartland at isharp.co.uk > West Midlands > England > ISHARP > DDI - 01922 472031 > Mobile - 07730 523179 > > > > _______________________________________________ > > * This message is confidential. > * This email, its content and any files transmitted with it are intended solely for the addressee and may be legally privileged and/or confidential. > * Access by any other party is unauthorised without the express written permission of the sender. > * If you have received this email in error you may not copy or use the contents, attachments or information in any way and any review, use, dissemination, forwarding, disclosure, alteration, printing of this information is strictly prohibited. Please destroy it and notify the sender via return e-mail. > * This email has been prepared using information believed by Paul Hartland to be reliable and accurate, but the company makes no warranty as to accuracy or completeness. In particular the author does not accept responsibility for changes made to this email after it was sent. > * Any opinions expressed in this document are those of the author and do not necessarily reflect the opinions of the company or its affiliates. > > The Orridge web site can be found at: > http://www.orridge.co.uk > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From Paul.Hartland at orridge.co.uk Fri May 27 05:50:16 2005 From: Paul.Hartland at orridge.co.uk (Paul Hartland) Date: Fri, 27 May 2005 11:50:16 +0100 Subject: [dba-SQLServer] Stored Procedures - Returning A Value Message-ID: <14A7AB003EFD444BBB193A23128DA20E264EFC@AL-PRI.Aldridge.local> To all, I'm sure this can be done, but I'm not advanced enough and can't seem to find it in books online. I have the following Stored Procedure (SQL Server 2000): CREATE PROCEDURE [genesis_insert_UserLog] ( @UserName [nvarchar](75), @TodayDate [datetime], @LogonTime [datetime], @CompName [nvarchar](75), @IPAddress [nvarchar](75) ) AS SET NOCOUNT ON INSERT INTO [GenesisBeta].[dbo].[tblUserLog] ( [UserName], [Logon_Date], [Logon_Time], [Computer_Name], [IP_Address], [IP_Host_Name] ) VALUES ( @UserName, @TodayDate, @LogonTime, @CompName, @IPAddress, @CompName ) SET NOCOUNT OFF GO Works fine, but I have a field in tblUserLog called LogonID which is an autonumber and I would like to return the value to a variable in Visual Basic 6 after the insert takes place. Anyone any ideas ow I would go about this ? Thanks in advance for any help.... PAUL HARTLAND Database Designer/Programmer paul.hartland at isharp.co.uk ISHARP DDI - 01922 472031 Mobile - 07730 523179 ISHARP (Information Services for Hospitality, Audit, Retail and Pharmacy) provide IT resources for the Christie Group Stock & Inventory Services companies. _______________________________________________ * This message is confidential. * This email, its content and any files transmitted with it are intended solely for the addressee and may be legally privileged and/or confidential. * Access by any other party is unauthorised without the express written permission of the sender. * If you have received this email in error you may not copy or use the contents, attachments or information in any way and any review, use, dissemination, forwarding, disclosure, alteration, printing of this information is strictly prohibited. Please destroy it and notify the sender via return e-mail. * This email has been prepared using information believed by Paul Hartland to be reliable and accurate, but the company makes no warranty as to accuracy or completeness. In particular the author does not accept responsibility for changes made to this email after it was sent. * Any opinions expressed in this document are those of the author and do not necessarily reflect the opinions of the company or its affiliates. The Orridge web site can be found at: http://www.orridge.co.uk From stuart at lexacorp.com.pg Fri May 27 06:27:16 2005 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Fri, 27 May 2005 21:27:16 +1000 Subject: [dba-SQLServer] Stored Procedures - Returning A Value In-Reply-To: <14A7AB003EFD444BBB193A23128DA20E264EFC@AL-PRI.Aldridge.local> Message-ID: <429790B4.15244.CF80E53@stuart.lexacorp.com.pg> On 27 May 2005 at 11:50, Paul Hartland wrote: > > Works fine, but I have a field in tblUserLog called LogonID which is an > autonumber and I would like to return the value to a variable in Visual > Basic 6 after the insert takes place. > > Anyone any ideas ow I would go about this ? > >From BOL: @@IDENTITY (T-SQL) Returns the last-inserted identity value. Syntax @@IDENTITY Return Types numeric Remarks After an INSERT, SELECT INTO, or bulk copy statement completes, @@IDENTITY contains the last identity value generated by the statement. If the statement did not affect any tables with identity columns, @@IDENTITY returns NULL. If multiple rows are inserted, generating multiple identity values, @@IDENTITY returns the last identity value generated. If the statement fires one or more triggers that perform inserts that generate identity values, calling @@IDENTITY immediately after the statement returns the last identity value generated by the triggers. The @@IDENTITY value does not revert to a previous setting if the INSERT or SELECT INTO statement or bulk copy fails, or if the transaction is rolled back. Examples This example inserts a row into a table with an identity column and uses @@IDENTITY to display the identity value used in the new row. INSERT INTO jobs (job_desc,min_lvl,max_lvl) VALUES ('Accountant',12,125) SELECT @@IDENTITY AS 'Identity' -- Stuart From paul.hartland at fsmail.net Fri May 27 06:31:02 2005 From: paul.hartland at fsmail.net (paul.hartland at fsmail.net) Date: Fri, 27 May 2005 13:31:02 +0200 (CEST) Subject: [dba-SQLServer] Stored Procedures - Returning A Value Message-ID: <766167.1117193462951.JavaMail.www@wwinf3103> Thanks, will try that in a minute Message date : May 27 2005, 12:27 PM >From : "Stuart McLachlan" To : dba-sqlserver at databaseadvisors.com Copy to : Subject : Re: [dba-SQLServer] Stored Procedures - Returning A Value On 27 May 2005 at 11:50, Paul Hartland wrote: > > Works fine, but I have a field in tblUserLog called LogonID which is an > autonumber and I would like to return the value to a variable in Visual > Basic 6 after the insert takes place. > > Anyone any ideas ow I would go about this ? > >From BOL: @@IDENTITY (T-SQL) Returns the last-inserted identity value. Syntax @@IDENTITY Return Types numeric Remarks After an INSERT, SELECT INTO, or bulk copy statement completes, @@IDENTITY contains the last identity value generated by the statement. If the statement did not affect any tables with identity columns, @@IDENTITY returns NULL. If multiple rows are inserted, generating multiple identity values, @@IDENTITY returns the last identity value generated. If the statement fires one or more triggers that perform inserts that generate identity values, calling @@IDENTITY immediately after the statement returns the last identity value generated by the triggers. The @@IDENTITY value does not revert to a previous setting if the INSERT or SELECT INTO statement or bulk copy fails, or if the transaction is rolled back. Examples This example inserts a row into a table with an identity column and uses @@IDENTITY to display the identity value used in the new row. INSERT INTO jobs (job_desc,min_lvl,max_lvl) VALUES ('Accountant',12,125) SELECT @@IDENTITY AS 'Identity' -- Stuart _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com -- Whatever you Wanadoo: http://www.wanadoo.co.uk/time/ This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm From rl_stewart at highstream.net Fri May 27 08:33:27 2005 From: rl_stewart at highstream.net (Robert L. Stewart) Date: Fri, 27 May 2005 08:33:27 -0500 Subject: [dba-SQLServer] Re: Truncate Log On Checkpoint In-Reply-To: <200505261700.j4QH0Os29686@databaseadvisors.com> Message-ID: <5.1.0.14.2.20050527083127.041c09d0@pop3.highstream.net> Paul, Here is the stored procedure that I include in all my databases to do teh log stuff. CREATE PROCEDURE dbo.TruncateLog AS begin exec sp_dboption 'clientaware','trunc.log on chkpt.','TRUE' end begin checkpoint end begin dbcc shrinkfile(clientaware_log,1) end GO Just replace clientaware with the name of you database and/or log file name. Robert At 12:00 PM 5/26/2005 -0500, you wrote: >Date: Thu, 26 May 2005 13:30:44 +0100 >From: "Paul Hartland" >Subject: [dba-SQLServer] Truncate Log On Checkpoint >To: >Message-ID: > <14A7AB003EFD444BBB193A23128DA20E264E54 at AL-PRI.Aldridge.local> >Content-Type: text/plain; charset="US-ASCII" > > To all, > > I want to be able to turn on the following option in a SQL >Server 2000 database - trunc. log on chkpt > but can't for the life of me see where I do this, I am quite new >to SQL Server and have never used this option before but think it will >be quite useful. > > Can anyone help me on this..... > > Thanks in advance for any help..... > > >PAUL HARTLAND From James at fcidms.com Fri May 27 08:38:18 2005 From: James at fcidms.com (James Barash) Date: Fri, 27 May 2005 09:38:18 -0400 Subject: [dba-SQLServer] Stored Procedures - Returning A Value In-Reply-To: <14A7AB003EFD444BBB193A23128DA20E264EFC@AL-PRI.Aldridge.local> Message-ID: <0IH500A9GHTTNY@mta8.srv.hcvlny.cv.net> Paul: You can use the function SCOPE_IDENTITY( ) to return the last inserted Identity field from the current procedure. You can also use @@IDENTITY, but that has some odd concurrency issues, especially with triggers. Look up either in BOL and you'll get all the gory details. Hope this helps. James Barash -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Paul Hartland Sent: Friday, May 27, 2005 6:50 AM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Stored Procedures - Returning A Value To all, I'm sure this can be done, but I'm not advanced enough and can't seem to find it in books online. I have the following Stored Procedure (SQL Server 2000): CREATE PROCEDURE [genesis_insert_UserLog] ( @UserName [nvarchar](75), @TodayDate [datetime], @LogonTime [datetime], @CompName [nvarchar](75), @IPAddress [nvarchar](75) ) AS SET NOCOUNT ON INSERT INTO [GenesisBeta].[dbo].[tblUserLog] ( [UserName], [Logon_Date], [Logon_Time], [Computer_Name], [IP_Address], [IP_Host_Name] ) VALUES ( @UserName, @TodayDate, @LogonTime, @CompName, @IPAddress, @CompName ) SET NOCOUNT OFF GO Works fine, but I have a field in tblUserLog called LogonID which is an autonumber and I would like to return the value to a variable in Visual Basic 6 after the insert takes place. Anyone any ideas ow I would go about this ? Thanks in advance for any help.... PAUL HARTLAND Database Designer/Programmer paul.hartland at isharp.co.uk ISHARP DDI - 01922 472031 Mobile - 07730 523179 ISHARP (Information Services for Hospitality, Audit, Retail and Pharmacy) provide IT resources for the Christie Group Stock & Inventory Services companies. _______________________________________________ * This message is confidential. * This email, its content and any files transmitted with it are intended solely for the addressee and may be legally privileged and/or confidential. * Access by any other party is unauthorised without the express written permission of the sender. * If you have received this email in error you may not copy or use the contents, attachments or information in any way and any review, use, dissemination, forwarding, disclosure, alteration, printing of this information is strictly prohibited. Please destroy it and notify the sender via return e-mail. * This email has been prepared using information believed by Paul Hartland to be reliable and accurate, but the company makes no warranty as to accuracy or completeness. In particular the author does not accept responsibility for changes made to this email after it was sent. * Any opinions expressed in this document are those of the author and do not necessarily reflect the opinions of the company or its affiliates. The Orridge web site can be found at: http://www.orridge.co.uk _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From paul.hartland at fsmail.net Fri May 27 09:07:01 2005 From: paul.hartland at fsmail.net (paul.hartland at fsmail.net) Date: Fri, 27 May 2005 16:07:01 +0200 (CEST) Subject: [dba-SQLServer] Re: Truncate Log On Checkpoint Message-ID: <32346798.1117202821156.JavaMail.www@wwinf3102> Thanks very much, will give that a try later Message date : May 27 2005, 02:35 PM >From : "Robert L. Stewart" To : dba-sqlserver at databaseadvisors.com Copy to : Paul.Hartland at orridge.co.uk Subject : [dba-SQLServer] Re: Truncate Log On Checkpoint Paul, Here is the stored procedure that I include in all my databases to do teh log stuff. CREATE PROCEDURE dbo.TruncateLog AS begin exec sp_dboption 'clientaware','trunc.log on chkpt.','TRUE' end begin checkpoint end begin dbcc shrinkfile(clientaware_log,1) end GO Just replace clientaware with the name of you database and/or log file name. Robert At 12:00 PM 5/26/2005 -0500, you wrote: >Date: Thu, 26 May 2005 13:30:44 +0100 >From: "Paul Hartland" >Subject: [dba-SQLServer] Truncate Log On Checkpoint >To: >Message-ID: > <14A7AB003EFD444BBB193A23128DA20E264E54 at AL-PRI.Aldridge.local> >Content-Type: text/plain; charset="US-ASCII" > > To all, > > I want to be able to turn on the following option in a SQL >Server 2000 database - trunc. log on chkpt > but can't for the life of me see where I do this, I am quite new >to SQL Server and have never used this option before but think it will >be quite useful. > > Can anyone help me on this..... > > Thanks in advance for any help..... > > >PAUL HARTLAND _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com -- Whatever you Wanadoo: http://www.wanadoo.co.uk/time/ This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm From cfoust at infostatsystems.com Tue May 31 17:02:51 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 31 May 2005 15:02:51 -0700 Subject: [dba-SQLServer] Import Errors Message-ID: I'm beating my head against some import errors that don't make much sense. I've got an Access FE with linked SQL Server tables and one table is giving me "Null value in an auto-number field" errors for two fields, neither of which is an autonumber. One of them is actually a text field declared as varchar in SQL Server. The other is declared as a smallint, but is set to allow nulls and is not required. Neither is set as an identity field. HELP! Charlotte Foust Infostat Systems, Inc. From ssharkins at bellsouth.net Tue May 31 17:16:19 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Tue, 31 May 2005 18:16:19 -0400 Subject: [dba-SQLServer] Import Errors In-Reply-To: Message-ID: <20050531221620.SPQP1856.ibm58aec.bellsouth.net@SUSANONE> Charlotte, would it be possible to create a mock table with the same settings and link to it to see if you get the same error? If not, you could just import the data into the new table. I've seen phantom characters cause this kind of mischief in Access, and you'll never find the culprit. Susan H. I'm beating my head against some import errors that don't make much sense. I've got an Access FE with linked SQL Server tables and one table is giving me "Null value in an auto-number field" errors for two fields, neither of which is an autonumber. One of them is actually a text field declared as varchar in SQL Server. The other is declared as a smallint, but is set to allow nulls and is not required. Neither is set as an identity field. HELP! From cfoust at infostatsystems.com Tue May 31 17:30:25 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 31 May 2005 15:30:25 -0700 Subject: [dba-SQLServer] Import Errors SOLVED Message-ID: Actually, it dawned on me that the records were being imported into a temp table first and when I checked, the fields, which were checked to allow nulls in the ultimate destination table, were missing that property in the temp table. Fortunately, I wasn't the one who created them. ;-> Charlotte Foust -----Original Message----- From: Susan Harkins [mailto:ssharkins at bellsouth.net] Sent: Tuesday, May 31, 2005 3:16 PM To: dba-sqlserver at databaseadvisors.com Subject: RE: [dba-SQLServer] Import Errors Charlotte, would it be possible to create a mock table with the same settings and link to it to see if you get the same error? If not, you could just import the data into the new table. I've seen phantom characters cause this kind of mischief in Access, and you'll never find the culprit. Susan H. I'm beating my head against some import errors that don't make much sense. I've got an Access FE with linked SQL Server tables and one table is giving me "Null value in an auto-number field" errors for two fields, neither of which is an autonumber. One of them is actually a text field declared as varchar in SQL Server. The other is declared as a smallint, but is set to allow nulls and is not required. Neither is set as an identity field. HELP! _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From artful at rogers.com Tue May 31 17:32:05 2005 From: artful at rogers.com (Arthur Fuller) Date: Tue, 31 May 2005 18:32:05 -0400 Subject: [dba-SQLServer] Walk through the controls on a given form In-Reply-To: <20050531221620.SPQP1856.ibm58aec.bellsouth.net@SUSANONE> References: <20050531221620.SPQP1856.ibm58aec.bellsouth.net@SUSANONE> Message-ID: <429CE5E5.8090703@rogers.com> I'm asking here because I need this to be ADO code not DAO. I already have a For Each loop that walks all the forms in an ADP. Now I want to add to this a call to a sub that walks the collection of controls on the given form and looks at combos and listboxes, printing their rowsource. Anybody got a chunk of code like that? TIA, Arthur From mikedorism at verizon.net Tue May 31 17:32:54 2005 From: mikedorism at verizon.net (Mike & Doris Manning) Date: Tue, 31 May 2005 18:32:54 -0400 Subject: [dba-SQLServer] Import Errors In-Reply-To: Message-ID: <000001c56630$b19a9b10$2f01a8c0@hargrove.internal> Charlotte, How are the fields set up in the original source? Doris Manning Database Administrator Hargrove Inc. www.hargroveinc.com -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Tuesday, May 31, 2005 6:03 PM To: dba-SQLServer at databaseadvisors.com Subject: [dba-SQLServer] Import Errors I'm beating my head against some import errors that don't make much sense. I've got an Access FE with linked SQL Server tables and one table is giving me "Null value in an auto-number field" errors for two fields, neither of which is an autonumber. One of them is actually a text field declared as varchar in SQL Server. The other is declared as a smallint, but is set to allow nulls and is not required. Neither is set as an identity field. HELP! Charlotte Foust Infostat Systems, Inc. _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From ssharkins at bellsouth.net Tue May 31 17:32:52 2005 From: ssharkins at bellsouth.net (Susan Harkins) Date: Tue, 31 May 2005 18:32:52 -0400 Subject: [dba-SQLServer] Import Errors SOLVED In-Reply-To: Message-ID: <20050531223253.MJKS8050.ibm62aec.bellsouth.net@SUSANONE> Well, I like it much better when there's a logical explanation. :) Susan H. Actually, it dawned on me that the records were being imported into a temp table first and when I checked, the fields, which were checked to allow nulls in the ultimate destination table, were missing that property in the temp table. Fortunately, I wasn't the one who created them. ;-> From cfoust at infostatsystems.com Tue May 31 17:36:54 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 31 May 2005 15:36:54 -0700 Subject: [dba-SQLServer] Walk through the controls on a given form Message-ID: ADO doesn't know about controls, Arthur. You should be able to use DAO code, even in an ADP, for that purpose. Charlotte Foust -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Tuesday, May 31, 2005 3:32 PM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Walk through the controls on a given form I'm asking here because I need this to be ADO code not DAO. I already have a For Each loop that walks all the forms in an ADP. Now I want to add to this a call to a sub that walks the collection of controls on the given form and looks at combos and listboxes, printing their rowsource. Anybody got a chunk of code like that? TIA, Arthur _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fhtapia at gmail.com Tue May 31 17:53:42 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 31 May 2005 15:53:42 -0700 Subject: [dba-SQLServer] Search your database.... Message-ID: Our company has been moving a lot of web content into SQL Server databases... the purpose was to make them searchable. I'm not exactly sure how to go about searching the ntext fields for this information.. I'm thinking like, but is there a better method than the "like" operator? maybe IN or EXISTS? -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From cfoust at infostatsystems.com Tue May 31 17:55:05 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 31 May 2005 15:55:05 -0700 Subject: [dba-SQLServer] Search your database.... Message-ID: Regular Expressions? Charlotte Foust -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: Tuesday, May 31, 2005 3:54 PM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Search your database.... Our company has been moving a lot of web content into SQL Server databases... the purpose was to make them searchable. I'm not exactly sure how to go about searching the ntext fields for this information.. I'm thinking like, but is there a better method than the "like" operator? maybe IN or EXISTS? -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fhtapia at gmail.com Tue May 31 17:58:19 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 31 May 2005 15:58:19 -0700 Subject: [dba-SQLServer] Search your database.... In-Reply-To: References: Message-ID: Yeah I forgot to mention, sorta like in the guise of Google/yahoo/msn etc.. SEARCH [ Machine +RPM -small ] would yeild all text w/ the word Machine and RPM but also exlcude the text w/ the word "small" On 5/31/05, Charlotte Foust wrote: > Regular Expressions? > > Charlotte Foust > > > -----Original Message----- > From: Francisco Tapia [mailto:fhtapia at gmail.com] > Sent: Tuesday, May 31, 2005 3:54 PM > To: dba-sqlserver at databaseadvisors.com > Subject: [dba-SQLServer] Search your database.... > > > Our company has been moving a lot of web content into SQL Server > databases... the purpose was to make them searchable. I'm not exactly > sure how to go about searching the ntext fields for this information.. > I'm thinking like, but is there a better method than the "like" > operator? > > maybe IN or EXISTS? -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... From cfoust at infostatsystems.com Tue May 31 18:08:13 2005 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 31 May 2005 16:08:13 -0700 Subject: [dba-SQLServer] Search your database.... Message-ID: So are you saying you *can't* use regular expressions?? Charlotte Foust -----Original Message----- From: Francisco Tapia [mailto:fhtapia at gmail.com] Sent: Tuesday, May 31, 2005 3:58 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Search your database.... Yeah I forgot to mention, sorta like in the guise of Google/yahoo/msn etc.. SEARCH [ Machine +RPM -small ] would yeild all text w/ the word Machine and RPM but also exlcude the text w/ the word "small" On 5/31/05, Charlotte Foust wrote: > Regular Expressions? > > Charlotte Foust > > > -----Original Message----- > From: Francisco Tapia [mailto:fhtapia at gmail.com] > Sent: Tuesday, May 31, 2005 3:54 PM > To: dba-sqlserver at databaseadvisors.com > Subject: [dba-SQLServer] Search your database.... > > > Our company has been moving a lot of web content into SQL Server > databases... the purpose was to make them searchable. I'm not exactly > sure how to go about searching the ntext fields for this information.. > I'm thinking like, but is there a better method than the "like" > operator? > > maybe IN or EXISTS? -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fhtapia at gmail.com Tue May 31 18:10:15 2005 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 31 May 2005 16:10:15 -0700 Subject: [dba-SQLServer] Search your database.... In-Reply-To: References: Message-ID: Well a bit more googling turned up what I need, tho I'm still reading the article, I hope this is all that is needed, anybody have any special tricks, or caveats?... http://www.databasejournal.com/features/mssql/article.php/3441981 On 5/31/05, Francisco Tapia wrote: > Yeah I forgot to mention, sorta like in the guise of Google/yahoo/msn etc.. > > > SEARCH [ Machine +RPM -small ] > > would yeild all text w/ the word Machine and RPM but also exlcude the > text w/ the word "small" > > On 5/31/05, Charlotte Foust wrote: > > Regular Expressions? > > > > Charlotte Foust > > > > > > -----Original Message----- > > From: Francisco Tapia [mailto:fhtapia at gmail.com] > > Sent: Tuesday, May 31, 2005 3:54 PM > > To: dba-sqlserver at databaseadvisors.com > > Subject: [dba-SQLServer] Search your database.... > > > > > > Our company has been moving a lot of web content into SQL Server > > databases... the purpose was to make them searchable. I'm not exactly > > sure how to go about searching the ntext fields for this information.. > > I'm thinking like, but is there a better method than the "like" > > operator? > > > > maybe IN or EXISTS? > > > > -- > -Francisco > http://pcthis.blogspot.com |PC news with out the jargon! > http://sqlthis.blogspot.com | Tsql and More... > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More...