Best practise to provide non-DBAs querying capabilities in SQL200

When we used SQLServer 2000, we installed just query analyzer on desktops of
several of our IT folks so they could query data easily. Some of these folks
have admin priv for non-DBA reasons. Now that querying data is integrated
into the SQL 2005 management studio I am not sure the best way to provide
this function to these users. I don't want to give the full management
studio, especially to those with Admin but no appreciation for DBA tasks.
Any thoughts would be appreciated.
Thanks
--
FloraPerhaps QALite work against 2005?
http://rac4sql.net/qalite_main.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Flora Seymour" <FloraSeymour@.discussions.microsoft.com> wrote in message
news:66C0EC4F-ACDB-47DB-9417-5258409A9584@.microsoft.com...
> When we used SQLServer 2000, we installed just query analyzer on desktops of
> several of our IT folks so they could query data easily. Some of these folks
> have admin priv for non-DBA reasons. Now that querying data is integrated
> into the SQL 2005 management studio I am not sure the best way to provide
> this function to these users. I don't want to give the full management
> studio, especially to those with Admin but no appreciation for DBA tasks.
> Any thoughts would be appreciated.
> Thanks
> --
> Flora|||Thanks - I'd rather stay within the MS SQL Server2005 product if possible,
but QALite may do the trick if I that does not work out. The info I found
on it does not mention SQL2005 , just SQL2000, SQL Server7. Any experience
with QALite on SQL2005?
--
Flora
"Flora Seymour" wrote:
> When we used SQLServer 2000, we installed just query analyzer on desktops of
> several of our IT folks so they could query data easily. Some of these folks
> have admin priv for non-DBA reasons. Now that querying data is integrated
> into the SQL 2005 management studio I am not sure the best way to provide
> this function to these users. I don't want to give the full management
> studio, especially to those with Admin but no appreciation for DBA tasks.
> Any thoughts would be appreciated.
> Thanks
> --
> Flora|||I haven't used QALite myself, but since the Query Analyzer (2000 version) work against 2005 (almost
all things), I think there's a good chance that QALite does as well.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Flora Seymour" <FloraSeymour@.discussions.microsoft.com> wrote in message
news:7E6DFEA1-4E1A-407C-938A-07EDB894F066@.microsoft.com...
> Thanks - I'd rather stay within the MS SQL Server2005 product if possible,
> but QALite may do the trick if I that does not work out. The info I found
> on it does not mention SQL2005 , just SQL2000, SQL Server7. Any experience
> with QALite on SQL2005?
> --
> Flora
>
> "Flora Seymour" wrote:
>> When we used SQLServer 2000, we installed just query analyzer on desktops of
>> several of our IT folks so they could query data easily. Some of these folks
>> have admin priv for non-DBA reasons. Now that querying data is integrated
>> into the SQL 2005 management studio I am not sure the best way to provide
>> this function to these users. I don't want to give the full management
>> studio, especially to those with Admin but no appreciation for DBA tasks.
>> Any thoughts would be appreciated.
>> Thanks
>> --
>> Flora

Best practise to provide non-DBAs querying capabilities in SQL200

When we used SQLServer 2000, we installed just query analyzer on desktops of
several of our IT folks so they could query data easily. Some of these folks
have admin priv for non-DBA reasons. Now that querying data is integrated
into the SQL 2005 management studio I am not sure the best way to provide
this function to these users. I don't want to give the full management
studio, especially to those with Admin but no appreciation for DBA tasks.
Any thoughts would be appreciated.
Thanks
--
FloraPerhaps QALite work against 2005?
http://rac4sql.net/qalite_main.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Flora Seymour" <FloraSeymour@.discussions.microsoft.com> wrote in message
news:66C0EC4F-ACDB-47DB-9417-5258409A9584@.microsoft.com...
> When we used SQLServer 2000, we installed just query analyzer on desktops
of
> several of our IT folks so they could query data easily. Some of these fol
ks
> have admin priv for non-DBA reasons. Now that querying data is integrated
> into the SQL 2005 management studio I am not sure the best way to provide
> this function to these users. I don't want to give the full management
> studio, especially to those with Admin but no appreciation for DBA tasks.
> Any thoughts would be appreciated.
> Thanks
> --
> Flora|||Thanks - I'd rather stay within the MS SQL Server2005 product if possible,
but QALite may do the trick if I that does not work out. The info I found
on it does not mention SQL2005 , just SQL2000, SQL Server7. Any experience
with QALite on SQL2005?
Flora
"Flora Seymour" wrote:

> When we used SQLServer 2000, we installed just query analyzer on desktops
of
> several of our IT folks so they could query data easily. Some of these fol
ks
> have admin priv for non-DBA reasons. Now that querying data is integrated
> into the SQL 2005 management studio I am not sure the best way to provide
> this function to these users. I don't want to give the full management
> studio, especially to those with Admin but no appreciation for DBA tasks.
> Any thoughts would be appreciated.
> Thanks
> --
> Flora|||I haven't used QALite myself, but since the Query Analyzer (2000 version) wo
rk against 2005 (almost
all things), I think there's a good chance that QALite does as well.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Flora Seymour" <FloraSeymour@.discussions.microsoft.com> wrote in message
news:7E6DFEA1-4E1A-407C-938A-07EDB894F066@.microsoft.com...[vbcol=seagreen]
> Thanks - I'd rather stay within the MS SQL Server2005 product if possible
,
> but QALite may do the trick if I that does not work out. The info I fou
nd
> on it does not mention SQL2005 , just SQL2000, SQL Server7. Any experience
> with QALite on SQL2005?
> --
> Flora
>
> "Flora Seymour" wrote:
>

Best Practice for SQL Server Null Values / Empty Strings

I'm fairly new to SQL Server. Coming from Acces, I see that Null values are handled differently. I've read many of the posts on querying Null values, but I want to know what is the best practice for designing a new system (SQL Server 2000) that could contain empty fields
For example, suppose I have a 'Phone' field that is often, but not always, filled in. If the user blanks out a phone number, the .NET DataAdapter .Update method will save the field as an empty string instead of a NULL. This of course makes every query more complex having to check for both nulls and empty strings
Is there any practical way to prevent, at the database level, the empty strings from getting into the database? (Perhaps triggers or some global setting?) Or should the string fields be empty strings and never nulls...? I could re-write the data adapter, but I don't know if I can trust that every program that touches the database will have handled the issue correctly
Any opionions
Thanks
Denis
using VB.Net and ADO.Net code and if the user blanks out a field, ADO.Net by default it sometimes saves them as an empty stringYou are totally right in your reseaech of null fields, did
you know that if you perform a string concatination with a
null it will always result in a null i.e
@.Forename = 'Denise'
@.Middlename = null
@.Surname = 'Smith'
Set @.Fullname = @.Forename + ' ' + @.Middlename + ' ' +
@.Surname
Will mean @.Fullname will be null.
However Nulls can also be useful i.e looking for NOT NULL,
and see the COALESCE statement, it really up to you.
If you want to get rid of null then you can use defaults.
The default will change a null to anything you want it to
be i.e '' or empty string.
To create a default
1. In EA go to the database
2. Select Defualts
3. Right click - select new defaults
4. Give it a name such as 'EmptyString'
Then when you create a column you can assign it the
default. This however will only work for new records and
not for existing ones.
J
>--Original Message--
>I'm fairly new to SQL Server. Coming from Acces, I see
that Null values are handled differently. I've read many
of the posts on querying Null values, but I want to know
what is the best practice for designing a new system (SQL
Server 2000) that could contain empty fields.
>For example, suppose I have a 'Phone' field that is
often, but not always, filled in. If the user blanks out
a phone number, the .NET DataAdapter .Update method will
save the field as an empty string instead of a NULL. This
of course makes every query more complex having to check
for both nulls and empty strings.
>Is there any practical way to prevent, at the database
level, the empty strings from getting into the database?
(Perhaps triggers or some global setting?) Or should the
string fields be empty strings and never nulls...? I
could re-write the data adapter, but I don't know if I can
trust that every program that touches the database will
have handled the issue correctly.
>Any opionions?
>Thanks,
>Denise
>
>using VB.Net and ADO.Net code and if the user blanks out
a field, ADO.Net by default it sometimes saves them as an
empty string
>.
>|||Denise,
I'll give you my opinion, for what it's worth.
A NULL means an unknown state. Therefore if you do not know the person's
phone number then it is unknown, therefore NULL.
An empty string is a positive entry into the database. It could be
interpreted as, "I KNOW that this value is empty" and could therefore be
interpreted as "this person doesn't have a phone".
This is a subtle difference to NULL. NULL just means "I don't know", or
unknown state. I doubt there is any performance difference between the
two, however I haven't tested it.
I'm not sure if I've actually answered your question because you need to
ensure you are passing NULLs to the database and not empty strings in
your data access layer code. If you want to prevent empty strings from
entering the database, then you could use a constraint like this:
--
create table a (i int not null, c varchar(30) null check (c <> ''))
insert a (i,c) values (1,null) -- succeeds
insert a (i,c) values (2,'') -- fails
select * from a
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Denise wrote:
> I'm fairly new to SQL Server. Coming from Acces, I see that Null
values are handled differently. I've read many of the posts on querying
Null values, but I want to know what is the best practice for designing
a new system (SQL Server 2000) that could contain empty fields.
> For example, suppose I have a 'Phone' field that is often, but not
always, filled in. If the user blanks out a phone number, the .NET
DataAdapter .Update method will save the field as an empty string
instead of a NULL. This of course makes every query more complex having
to check for both nulls and empty strings.
> Is there any practical way to prevent, at the database level, the
empty strings from getting into the database? (Perhaps triggers or some
global setting?) Or should the string fields be empty strings and never
nulls...? I could re-write the data adapter, but I don't know if I can
trust that every program that touches the database will have handled the
issue correctly.
> Any opionions?
> Thanks, Denise
>
> using VB.Net and ADO.Net code and if the user blanks out a field, ADO.Net by default it sometimes saves them as an empty string|||Julie,
(just to point out that the first part of your response is not always
necessarily the case:)
SET CONCAT_NULL_YIELDS_NULL ON
select null + 'hello'
SET CONCAT_NULL_YIELDS_NULL OFF
select null + 'hello'
Regards,
Paul Ibison|||There are strong debates regarding whether or not nulls should ever be
allowed in data columns. I agree with Mark, if you do not know the value
allow null ( even though it may require programming on the front end.)
Others ( Kalen Delaney for instance) make strong arguments for never
allowing nulls in the database.
This is an area where reasonable people differ in their opinions, so do
whatever works for you, with a clear conscience..
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
news:O07qtuHSEHA.2000@.TK2MSFTNGP11.phx.gbl...
> Denise,
> I'll give you my opinion, for what it's worth.
> A NULL means an unknown state. Therefore if you do not know the person's
> phone number then it is unknown, therefore NULL.
> An empty string is a positive entry into the database. It could be
> interpreted as, "I KNOW that this value is empty" and could therefore be
> interpreted as "this person doesn't have a phone".
> This is a subtle difference to NULL. NULL just means "I don't know", or
> unknown state. I doubt there is any performance difference between the
> two, however I haven't tested it.
> I'm not sure if I've actually answered your question because you need to
> ensure you are passing NULLs to the database and not empty strings in
> your data access layer code. If you want to prevent empty strings from
> entering the database, then you could use a constraint like this:
> --
> create table a (i int not null, c varchar(30) null check (c <> ''))
> insert a (i,c) values (1,null) -- succeeds
> insert a (i,c) values (2,'') -- fails
> select * from a
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> Denise wrote:
> > I'm fairly new to SQL Server. Coming from Acces, I see that Null
> values are handled differently. I've read many of the posts on querying
> Null values, but I want to know what is the best practice for designing
> a new system (SQL Server 2000) that could contain empty fields.
> >
> > For example, suppose I have a 'Phone' field that is often, but not
> always, filled in. If the user blanks out a phone number, the .NET
> DataAdapter .Update method will save the field as an empty string
> instead of a NULL. This of course makes every query more complex having
> to check for both nulls and empty strings.
> >
> > Is there any practical way to prevent, at the database level, the
> empty strings from getting into the database? (Perhaps triggers or some
> global setting?) Or should the string fields be empty strings and never
> nulls...? I could re-write the data adapter, but I don't know if I can
> trust that every program that touches the database will have handled the
> issue correctly.
> >
> > Any opionions?
> >
> > Thanks, Denise
> >
> >
> > using VB.Net and ADO.Net code and if the user blanks out a field,
ADO.Net by default it sometimes saves them as an empty string|||you've definately opened a can of worms. (Religious topic)
Many argue that nulls suggest a normalization problem.
Nulls will cause performance issues
Nulls will force you to add handling into your sprocs etc.
it's your call of course whether or not you wish to use them.
I lean towards not using them except in rare situations, but that's just me.
Cheers,
Greg Jackson
PDX, Oregon|||Thanks for all your insight.

Best Practice for SQL Server Null Values / Empty Strings

I'm fairly new to SQL Server. Coming from Acces, I see that Null values are
handled differently. I've read many of the posts on querying Null values,
but I want to know what is the best practice for designing a new system (SQL
Server 2000) that could co
ntain empty fields.
For example, suppose I have a 'Phone' field that is often, but not always, f
illed in. If the user blanks out a phone number, the .NET DataAdapter .Upda
te method will save the field as an empty string instead of a NULL. This of
course makes every query m
ore complex having to check for both nulls and empty strings.
Is there any practical way to prevent, at the database level, the empty stri
ngs from getting into the database? (Perhaps triggers or some global settin
g?) Or should the string fields be empty strings and never nulls...? I cou
ld re-write the data adapte
r, but I don't know if I can trust that every program that touches the datab
ase will have handled the issue correctly.
Any opionions?
Thanks,
Denise
using VB.Net and ADO.Net code and if the user blanks out a field, ADO.Net by
default it sometimes saves them as an empty stringDenise,
I'll give you my opinion, for what it's worth.
A NULL means an unknown state. Therefore if you do not know the person's
phone number then it is unknown, therefore NULL.
An empty string is a positive entry into the database. It could be
interpreted as, "I KNOW that this value is empty" and could therefore be
interpreted as "this person doesn't have a phone".
This is a subtle difference to NULL. NULL just means "I don't know", or
unknown state. I doubt there is any performance difference between the
two, however I haven't tested it.
I'm not sure if I've actually answered your question because you need to
ensure you are passing NULLs to the database and not empty strings in
your data access layer code. If you want to prevent empty strings from
entering the database, then you could use a constraint like this:
create table a (i int not null, c varchar(30) null check (c <> ''))
insert a (i,c) values (1,null) -- succeeds
insert a (i,c) values (2,'') -- fails
select * from a
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Denise wrote:
> I'm fairly new to SQL Server. Coming from Acces, I see that Null
values are handled differently. I've read many of the posts on querying
Null values, but I want to know what is the best practice for designing
a new system (SQL Server 2000) that could contain empty fields.
> For example, suppose I have a 'Phone' field that is often, but not
always, filled in. If the user blanks out a phone number, the .NET
DataAdapter .Update method will save the field as an empty string
instead of a NULL. This of course makes every query more complex having
to check for both nulls and empty strings.
> Is there any practical way to prevent, at the database level, the
empty strings from getting into the database? (Perhaps triggers or some
global setting?) Or should the string fields be empty strings and never
nulls...? I could re-write the data adapter, but I don't know if I can
trust that every program that touches the database will have handled the
issue correctly.
> Any opionions?
> Thanks, Denise
>
> using VB.Net and ADO.Net code and if the user blanks out a field, ADO.Net by defau
lt it sometimes saves them as an empty string|||There are strong debates regarding whether or not nulls should ever be
allowed in data columns. I agree with Mark, if you do not know the value
allow null ( even though it may require programming on the front end.)
Others ( Kalen Delaney for instance) make strong arguments for never
allowing nulls in the database.
This is an area where reasonable people differ in their opinions, so do
whatever works for you, with a clear conscience..
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
news:O07qtuHSEHA.2000@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> Denise,
> I'll give you my opinion, for what it's worth.
> A NULL means an unknown state. Therefore if you do not know the person's
> phone number then it is unknown, therefore NULL.
> An empty string is a positive entry into the database. It could be
> interpreted as, "I KNOW that this value is empty" and could therefore be
> interpreted as "this person doesn't have a phone".
> This is a subtle difference to NULL. NULL just means "I don't know", or
> unknown state. I doubt there is any performance difference between the
> two, however I haven't tested it.
> I'm not sure if I've actually answered your question because you need to
> ensure you are passing NULLs to the database and not empty strings in
> your data access layer code. If you want to prevent empty strings from
> entering the database, then you could use a constraint like this:
> --
> create table a (i int not null, c varchar(30) null check (c <> ''))
> insert a (i,c) values (1,null) -- succeeds
> insert a (i,c) values (2,'') -- fails
> select * from a
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> Denise wrote:
> values are handled differently. I've read many of the posts on querying
> Null values, but I want to know what is the best practice for designing
> a new system (SQL Server 2000) that could contain empty fields.
> always, filled in. If the user blanks out a phone number, the .NET
> DataAdapter .Update method will save the field as an empty string
> instead of a NULL. This of course makes every query more complex having
> to check for both nulls and empty strings.
> empty strings from getting into the database? (Perhaps triggers or some
> global setting?) Or should the string fields be empty strings and never
> nulls...? I could re-write the data adapter, but I don't know if I can
> trust that every program that touches the database will have handled the
> issue correctly.
ADO.Net by default it sometimes saves them as an empty string|||you've definately opened a can of worms. (Religious topic)
Many argue that nulls suggest a normalization problem.
Nulls will cause performance issues
Nulls will force you to add handling into your sprocs etc.
it's your call of course whether or not you wish to use them.
I lean towards not using them except in rare situations, but that's just me.
Cheers,
Greg Jackson
PDX, Oregon|||Thanks for all your insight.

Best Practice for SQL Server Null Values / Empty Strings

I'm fairly new to SQL Server. Coming from Acces, I see that Null values are handled differently. I've read many of the posts on querying Null values, but I want to know what is the best practice for designing a new system (SQL Server 2000) that could co
ntain empty fields.
For example, suppose I have a 'Phone' field that is often, but not always, filled in. If the user blanks out a phone number, the .NET DataAdapter .Update method will save the field as an empty string instead of a NULL. This of course makes every query m
ore complex having to check for both nulls and empty strings.
Is there any practical way to prevent, at the database level, the empty strings from getting into the database? (Perhaps triggers or some global setting?) Or should the string fields be empty strings and never nulls...? I could re-write the data adapte
r, but I don't know if I can trust that every program that touches the database will have handled the issue correctly.
Any opionions?
Thanks,
Denise
using VB.Net and ADO.Net code and if the user blanks out a field, ADO.Net by default it sometimes saves them as an empty string
Denise,
I'll give you my opinion, for what it's worth.
A NULL means an unknown state. Therefore if you do not know the person's
phone number then it is unknown, therefore NULL.
An empty string is a positive entry into the database. It could be
interpreted as, "I KNOW that this value is empty" and could therefore be
interpreted as "this person doesn't have a phone".
This is a subtle difference to NULL. NULL just means "I don't know", or
unknown state. I doubt there is any performance difference between the
two, however I haven't tested it.
I'm not sure if I've actually answered your question because you need to
ensure you are passing NULLs to the database and not empty strings in
your data access layer code. If you want to prevent empty strings from
entering the database, then you could use a constraint like this:
create table a (i int not null, c varchar(30) null check (c <> ''))
insert a (i,c) values (1,null) -- succeeds
insert a (i,c) values (2,'') -- fails
select * from a
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Denise wrote:
> I'm fairly new to SQL Server. Coming from Acces, I see that Null
values are handled differently. I've read many of the posts on querying
Null values, but I want to know what is the best practice for designing
a new system (SQL Server 2000) that could contain empty fields.
> For example, suppose I have a 'Phone' field that is often, but not
always, filled in. If the user blanks out a phone number, the .NET
DataAdapter .Update method will save the field as an empty string
instead of a NULL. This of course makes every query more complex having
to check for both nulls and empty strings.
> Is there any practical way to prevent, at the database level, the
empty strings from getting into the database? (Perhaps triggers or some
global setting?) Or should the string fields be empty strings and never
nulls...? I could re-write the data adapter, but I don't know if I can
trust that every program that touches the database will have handled the
issue correctly.
> Any opionions?
> Thanks, Denise
>
> using VB.Net and ADO.Net code and if the user blanks out a field, ADO.Net by default it sometimes saves them as an empty string
|||There are strong debates regarding whether or not nulls should ever be
allowed in data columns. I agree with Mark, if you do not know the value
allow null ( even though it may require programming on the front end.)
Others ( Kalen Delaney for instance) make strong arguments for never
allowing nulls in the database.
This is an area where reasonable people differ in their opinions, so do
whatever works for you, with a clear conscience..
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
news:O07qtuHSEHA.2000@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> Denise,
> I'll give you my opinion, for what it's worth.
> A NULL means an unknown state. Therefore if you do not know the person's
> phone number then it is unknown, therefore NULL.
> An empty string is a positive entry into the database. It could be
> interpreted as, "I KNOW that this value is empty" and could therefore be
> interpreted as "this person doesn't have a phone".
> This is a subtle difference to NULL. NULL just means "I don't know", or
> unknown state. I doubt there is any performance difference between the
> two, however I haven't tested it.
> I'm not sure if I've actually answered your question because you need to
> ensure you are passing NULLs to the database and not empty strings in
> your data access layer code. If you want to prevent empty strings from
> entering the database, then you could use a constraint like this:
> --
> create table a (i int not null, c varchar(30) null check (c <> ''))
> insert a (i,c) values (1,null) -- succeeds
> insert a (i,c) values (2,'') -- fails
> select * from a
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> Denise wrote:
> values are handled differently. I've read many of the posts on querying
> Null values, but I want to know what is the best practice for designing
> a new system (SQL Server 2000) that could contain empty fields.
> always, filled in. If the user blanks out a phone number, the .NET
> DataAdapter .Update method will save the field as an empty string
> instead of a NULL. This of course makes every query more complex having
> to check for both nulls and empty strings.
> empty strings from getting into the database? (Perhaps triggers or some
> global setting?) Or should the string fields be empty strings and never
> nulls...? I could re-write the data adapter, but I don't know if I can
> trust that every program that touches the database will have handled the
> issue correctly.
ADO.Net by default it sometimes saves them as an empty string
|||you've definately opened a can of worms. (Religious topic)
Many argue that nulls suggest a normalization problem.
Nulls will cause performance issues
Nulls will force you to add handling into your sprocs etc.
it's your call of course whether or not you wish to use them.
I lean towards not using them except in rare situations, but that's just me.
Cheers,
Greg Jackson
PDX, Oregon
|||Thanks for all your insight.

Begins With

I am trying to reduce the number of fax numbers I have in my access database querying out all numbers except 6 area codes.

I have tried to do:

SELECT FaxNumbers
FROM FAXList
WHERE FaxNumbers BEGINS WITH 972 OR 817 OR 214;

but it doesn't work, what am I doing wrong?Hi
Try the following query

select phone from users where phone like '301%' or phone like '201%' or phone like '212%';
Thanx and Regards
Aruneesh|||I have tried both the command BEGINS WITH 972 or 817 or 214 or 903 and LIKE 972% or 817% or 214% or 903%, and neither work. I get no results even though I know that there are some in there.

Can anybody help me?
Gurka|||Could u post the command u r using to query the DB.|||I think I got it to work.
I used * instead of %.

Gurka|||Gurka
Good luck with your query.
Aruneesh