Showing posts with label referencing. Show all posts
Showing posts with label referencing. Show all posts

Friday, March 30, 2012

Question about self referencing delete

Let's say we have table as follows.
empid mgrid empname
--
1 null abc
2 1 pqr
empid is primary key for the table
mgrid is self referencing foreign key towards empid
Now on above table, I execute DML as:
DELETE FROM emp_1 WHERE empid in (1, 2)
So SQLSerever, will first attempt to delete record where empid is 1. (Isn't
it?) And then SQLServer is supposed to give an error ; as empid = 1 is being
referred as foreign key in record where empid is 2. But it doesn't happen
so. SQLServer doesn't give an error. So does that mean SQLServer first
deletes record where empid is 2. And then it deletes the record where empid
is 1? (In short, deletes all cascading child records first and then parent
records) Is it SQLServer's normal and expected behavior? Or it is not
guaranteed? Or anything else? Please guide. Thanks.
Regards,
PravinThis is a multi-part message in MIME format.
--=_NextPart_000_0030_01C3745C.97B12C90
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Thanks Tom.
I got the point that because parent and child both are there in delete =statement, SQLServer doesn't throw an error.
However, another point you have specified is "In your case, you did not =specify ON DELETE CASCADE in your foreign key". Does that mean SQLServer =allows setting the option 'on delete cascade' for self referencing keys? =If yes, then please inform me how. If no, then your answer that "In your =DELETE, you specified that you were deleting both the child and the =related parent, so there would be no RI violation." is just the answer =for my question. Right?
Note: I was not able to set this option from enterprize manager. Please =guide, Thanks in Advance.
-- Regards,
Pravin Joshi
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message =news:errsWw9cDHA.828@.TK2MSFTNGP11.phx.gbl...
In your case, you did not specify ON DELETE CASCADE in your foreign =key. If you had, it would have failed, since it is a circular =reference. In your DELETE, you specified that you were deleting both =the child and the related parent, so there would be no RI violation. If =you try the following, it should fail:
DELETE FROM emp_1 WHERE empid =3D 1
-- Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Pravin" <expertco@.vsnl.com> wrote in message =news:OQxXPs9cDHA.456@.TK2MSFTNGP10.phx.gbl...
Let's say we have table as follows.
empid mgrid empname
--
1 null abc
2 1 pqr
empid is primary key for the table
mgrid is self referencing foreign key towards empid
Now on above table, I execute DML as:
DELETE FROM emp_1 WHERE empid in (1, 2)
So SQLSerever, will first attempt to delete record where empid is 1. =(Isn't
it?) And then SQLServer is supposed to give an error ; as empid =3D 1 =is being
referred as foreign key in record where empid is 2. But it doesn't =happen
so. SQLServer doesn't give an error. So does that mean SQLServer first
deletes record where empid is 2. And then it deletes the record where =empid
is 1? (In short, deletes all cascading child records first and then =parent
records) Is it SQLServer's normal and expected behavior? Or it is not
guaranteed? Or anything else? Please guide. Thanks.
Regards,
Pravin
--=_NextPart_000_0030_01C3745C.97B12C90
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

Thanks Tom.
I got the point that because parent =and child both are there in delete statement, SQLServer doesn't throw an error.
However, another point you have =specified is "In your case, you did not specify ON DELETE =CASCADE in your foreign key". Does that mean SQLServer allows setting the =option 'on delete cascade' for self referencing keys? If yes, then please inform me =how. If no, then your answer that "In your DELETE, you =specified that you were deleting both the child and the related parent, so there would =be no RI violation." is just the answer for my question. =Right?
Note: I was not able to set this =option from enterprize manager. Please guide, Thanks in Advance.
-- Regards,Pravin Joshi
"Tom Moreau" = wrote in message news:errsWw9cDHA.828@.T=K2MSFTNGP11.phx.gbl...
In your case, you did not specify ON =DELETE CASCADE in your foreign key. If you had, it would have failed, =since it is a circular reference. In your DELETE, you specified that you =were deleting both the child and the related parent, so there would be no =RI violation. If you try the following, it should =fail:

DELETE FROM emp_1 WHERE empid ==3D 1

-- Tom

=---T=homas A. Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL =Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql


"Pravin" wrote in message news:OQxXPs9cDHA.456@.T=K2MSFTNGP10.phx.gbl...Let's say we have table as follows.empid mgrid =empname--1 &nbs=p; null =abc2 1 pqrempid is primary key =for the tablemgrid is self referencing foreign key towards =empidNow on above table, I execute DML as: DELETE FROM emp_1 =WHERE empid in (1, 2)So SQLSerever, will first attempt to delete =record where empid is 1. (Isn'tit?) And then SQLServer is supposed to =give an error ; as empid =3D 1 is beingreferred as foreign key in record =where empid is 2. But it doesn't happenso. SQLServer doesn't give an error. So =does that mean SQLServer firstdeletes record where empid is 2. And then =it deletes the record where empidis 1? (In short, deletes all =cascading child records first and then parentrecords) Is it SQLServer's normal and = expected behavior? Or it is notguaranteed? Or anything else? =Please guide. =Thanks.Regards,Pravin

--=_NextPart_000_0030_01C3745C.97B12C90--|||This is a multi-part message in MIME format.
--=_NextPart_000_000F_01C37454.B43BD200
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
The point I was making was that you cannot use ON DELETE CASCADE in a =self-referencing situation. You should avoid using EM for creating =tables. I stick with scripting it out and then saving the scripts under =version control.
-- Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
.
"Pravin" <expertco@.vsnl.com> wrote in message =news:usF6m5CdDHA.560@.TK2MSFTNGP11.phx.gbl...
Thanks Tom.
I got the point that because parent and child both are there in delete =statement, SQLServer doesn't throw an error.
However, another point you have specified is "In your case, you did not =specify ON DELETE CASCADE in your foreign key". Does that mean SQLServer =allows setting the option 'on delete cascade' for self referencing keys? =If yes, then please inform me how. If no, then your answer that "In your =DELETE, you specified that you were deleting both the child and the =related parent, so there would be no RI violation." is just the answer =for my question. Right?
Note: I was not able to set this option from enterprize manager. Please =guide, Thanks in Advance.
-- Regards,
Pravin Joshi
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message =news:errsWw9cDHA.828@.TK2MSFTNGP11.phx.gbl...
In your case, you did not specify ON DELETE CASCADE in your foreign =key. If you had, it would have failed, since it is a circular =reference. In your DELETE, you specified that you were deleting both =the child and the related parent, so there would be no RI violation. If =you try the following, it should fail:
DELETE FROM emp_1 WHERE empid =3D 1
-- Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Pravin" <expertco@.vsnl.com> wrote in message =news:OQxXPs9cDHA.456@.TK2MSFTNGP10.phx.gbl...
Let's say we have table as follows.
empid mgrid empname
--
1 null abc
2 1 pqr
empid is primary key for the table
mgrid is self referencing foreign key towards empid
Now on above table, I execute DML as:
DELETE FROM emp_1 WHERE empid in (1, 2)
So SQLSerever, will first attempt to delete record where empid is 1. =(Isn't
it?) And then SQLServer is supposed to give an error ; as empid =3D 1 =is being
referred as foreign key in record where empid is 2. But it doesn't =happen
so. SQLServer doesn't give an error. So does that mean SQLServer first
deletes record where empid is 2. And then it deletes the record where =empid
is 1? (In short, deletes all cascading child records first and then =parent
records) Is it SQLServer's normal and expected behavior? Or it is not
guaranteed? Or anything else? Please guide. Thanks.
Regards,
Pravin
--=_NextPart_000_000F_01C37454.B43BD200
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

The point I was making was that you =cannot use ON DELETE CASCADE in a self-referencing situation. You should avoid =using EM for creating tables. I stick with scripting it out and then saving =the scripts under version control.
-- Tom
----Thomas A. =Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql.
"Pravin" wrote in message news:usF6m5CdDHA.560@.T=K2MSFTNGP11.phx.gbl...
Thanks Tom.
I got the point that because parent =and child both are there in delete statement, SQLServer doesn't throw an error.
However, another point you have =specified is "In your case, you did not specify ON DELETE =CASCADE in your foreign key". Does that mean SQLServer allows setting the =option 'on delete cascade' for self referencing keys? If yes, then please inform me =how. If no, then your answer that "In your DELETE, you =specified that you were deleting both the child and the related parent, so there would =be no RI violation." is just the answer for my question. =Right?
Note: I was not able to set this =option from enterprize manager. Please guide, Thanks in Advance.
-- Regards,Pravin Joshi
"Tom Moreau" = wrote in message news:errsWw9cDHA.828@.T=K2MSFTNGP11.phx.gbl...
In your case, you did not specify ON =DELETE CASCADE in your foreign key. If you had, it would have failed, =since it is a circular reference. In your DELETE, you specified that you =were deleting both the child and the related parent, so there would be no =RI violation. If you try the following, it should =fail:

DELETE FROM emp_1 WHERE empid ==3D 1

-- Tom

=---T=homas A. Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL =Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql


"Pravin" wrote in message news:OQxXPs9cDHA.456@.T=K2MSFTNGP10.phx.gbl...Let's say we have table as follows.empid mgrid =empname--1 &nbs=p; null =abc2 1 pqrempid is primary key =for the tablemgrid is self referencing foreign key towards =empidNow on above table, I execute DML as: DELETE FROM emp_1 =WHERE empid in (1, 2)So SQLSerever, will first attempt to delete =record where empid is 1. (Isn'tit?) And then SQLServer is supposed to =give an error ; as empid =3D 1 is beingreferred as foreign key in record =where empid is 2. But it doesn't happenso. SQLServer doesn't give an error. So =does that mean SQLServer firstdeletes record where empid is 2. And then =it deletes the record where empidis 1? (In short, deletes all =cascading child records first and then parentrecords) Is it SQLServer's normal and = expected behavior? Or it is notguaranteed? Or anything else? =Please guide. =Thanks.Regards,Pravin

--=_NextPart_000_000F_01C37454.B43BD200--|||This is a multi-part message in MIME format.
--=_NextPart_000_000D_01C374C4.4266C7F0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Ok Tom. That clears the doubt. Thanks.
-- Regards,
Pravin
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message =news:#aD7FZHdDHA.4020@.tk2msftngp13.phx.gbl...
The point I was making was that you cannot use ON DELETE CASCADE in a =self-referencing situation. You should avoid using EM for creating =tables. I stick with scripting it out and then saving the scripts under =version control.
-- Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
.
"Pravin" <expertco@.vsnl.com> wrote in message =news:usF6m5CdDHA.560@.TK2MSFTNGP11.phx.gbl...
Thanks Tom.
I got the point that because parent and child both are there in delete =statement, SQLServer doesn't throw an error.
However, another point you have specified is "In your case, you did =not specify ON DELETE CASCADE in your foreign key". Does that mean =SQLServer allows setting the option 'on delete cascade' for self =referencing keys? If yes, then please inform me how. If no, then your =answer that "In your DELETE, you specified that you were deleting both =the child and the related parent, so there would be no RI violation." is =just the answer for my question. Right?
Note: I was not able to set this option from enterprize manager. =Please guide, Thanks in Advance.
-- Regards,
Pravin Joshi
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message =news:errsWw9cDHA.828@.TK2MSFTNGP11.phx.gbl...
In your case, you did not specify ON DELETE CASCADE in your foreign =key. If you had, it would have failed, since it is a circular =reference. In your DELETE, you specified that you were deleting both =the child and the related parent, so there would be no RI violation. If =you try the following, it should fail:
DELETE FROM emp_1 WHERE empid =3D 1
-- Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Pravin" <expertco@.vsnl.com> wrote in message =news:OQxXPs9cDHA.456@.TK2MSFTNGP10.phx.gbl...
Let's say we have table as follows.
empid mgrid empname
--
1 null abc
2 1 pqr
empid is primary key for the table
mgrid is self referencing foreign key towards empid
Now on above table, I execute DML as:
DELETE FROM emp_1 WHERE empid in (1, 2)
So SQLSerever, will first attempt to delete record where empid is 1. =(Isn't
it?) And then SQLServer is supposed to give an error ; as empid =3D =1 is being
referred as foreign key in record where empid is 2. But it doesn't =happen
so. SQLServer doesn't give an error. So does that mean SQLServer =first
deletes record where empid is 2. And then it deletes the record =where empid
is 1? (In short, deletes all cascading child records first and then =parent
records) Is it SQLServer's normal and expected behavior? Or it is =not
guaranteed? Or anything else? Please guide. Thanks.
Regards,
Pravin
--=_NextPart_000_000D_01C374C4.4266C7F0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

Ok Tom. That clears the doubt. Thanks.
-- Regards,Pravin
"Tom Moreau" = wrote in message news:#aD7FZHdDHA.4020=@.tk2msftngp13.phx.gbl...
The point I was making was that you =cannot use ON DELETE CASCADE in a self-referencing situation. You should =avoid using EM for creating tables. I stick with scripting it out and =then saving the scripts under version control.
-- Tom

----Thomas A. =Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql.
"Pravin" wrote in message news:usF6m5CdDHA.560@.T=K2MSFTNGP11.phx.gbl...
Thanks Tom.

I got the point that because parent =and child both are there in delete statement, SQLServer doesn't throw an error.

However, another point you have =specified is "In your case, you did not specify ON DELETE =CASCADE in your foreign key". Does that mean SQLServer allows setting =the option 'on delete cascade' for self referencing keys? If yes, then =please inform me how. If no, then your answer that "In =your DELETE, you specified that you were deleting both the child and the related =parent, so there would be no RI violation." is just the answer for my =question. Right?

Note: I was not able to set =this option from enterprize manager. Please guide, Thanks in Advance.
-- Regards,Pravin Joshi
"Tom Moreau" = wrote in message news:errsWw9cDHA.828@.T=K2MSFTNGP11.phx.gbl...
In your case, you did not specify =ON DELETE CASCADE in your foreign key. If you had, it would have failed, =since it is a circular reference. In your DELETE, you specified that =you were deleting both the child and the related parent, so there would =be no RI violation. If you try the following, it should =fail:

DELETE FROM emp_1 WHERE =empid =3D 1

-- Tom

=---T=homas A. Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL =Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql


"Pravin" wrote in =message news:OQxXPs9cDHA.456@.T=K2MSFTNGP10.phx.gbl...Let's say we have table as follows.empid mgrid =empname--1 &nbs=p; null =abc2 1 pqrempid is primary =key for the tablemgrid is self referencing foreign key towards =empidNow on above table, I execute DML as: DELETE FROM =emp_1 WHERE empid in (1, 2)So SQLSerever, will first attempt to =delete record where empid is 1. (Isn'tit?) And then SQLServer is =supposed to give an error ; as empid =3D 1 is beingreferred as foreign key =in record where empid is 2. But it doesn't happenso. SQLServer doesn't =give an error. So does that mean SQLServer firstdeletes record where =empid is 2. And then it deletes the record where empidis 1? (In short, =deletes all cascading child records first and then parentrecords) Is it =SQLServer's normal and expected behavior? Or it is notguaranteed? Or =anything else? Please guide. Thanks.Regards,Pravin

--=_NextPart_000_000D_01C374C4.4266C7F0--sql

Wednesday, March 28, 2012

Question about referencing UDFs

OK - I've found pieces of the answer to this question in various places, but
never a complete one.
When referencing UDFs from TSQL, I know that table functions do not require
a "dbo." prefix (or any prefix for that matter), and that scalar functions d
o
require the prefix.
So what I want to know is, is it possible to use the "user" function (that
returns the current user) as the prefix instead of having to actually hard
code the user name? i.e. why can't I just do something like:
select user.myfunc()
instead of having to say:
select kingd.myfunc()
Is there another way to specify the current user?
Thanks in advance.
DKAre you saying you have different functions for every user, with the same
name? Yikes. Why not pass the USER_NAME() into the function and have the
logic there, instead of having to maintain an object per user? Who is going
to maintain these functions as users are added/removed?
"Dwayne King" <dwayne.king@.cognos.com> wrote in message
news:D905030B-4E3F-4543-93A4-E0EE1B95DC74@.microsoft.com...
> OK - I've found pieces of the answer to this question in various places,
> but
> never a complete one.
> When referencing UDFs from TSQL, I know that table functions do not
> require
> a "dbo." prefix (or any prefix for that matter), and that scalar functions
> do
> require the prefix.
> So what I want to know is, is it possible to use the "user" function (that
> returns the current user) as the prefix instead of having to actually hard
> code the user name? i.e. why can't I just do something like:
> select user.myfunc()
> instead of having to say:
> select kingd.myfunc()
> Is there another way to specify the current user?
> Thanks in advance.
>
> --
> DK|||Dwayne King,
It is not the "dbo" prefix, neither the user name. it is the owner of the
object.
What do think will happen when a user, that is not the function owner,
executes the statement?
SQL Server will look for user_no_owner.myfunc() and this will yield an error
.
AMB
"Dwayne King" wrote:

> OK - I've found pieces of the answer to this question in various places, b
ut
> never a complete one.
> When referencing UDFs from TSQL, I know that table functions do not requir
e
> a "dbo." prefix (or any prefix for that matter), and that scalar functions
do
> require the prefix.
> So what I want to know is, is it possible to use the "user" function (that
> returns the current user) as the prefix instead of having to actually hard
> code the user name? i.e. why can't I just do something like:
> select user.myfunc()
> instead of having to say:
> select kingd.myfunc()
> Is there another way to specify the current user?
> Thanks in advance.
>
> --
> DK|||Sorry - I haven't explained myself very well.
There is only one user and one set of functions. The problem is, this is a
product that our customer installs, and we allow them to choose what user to
install the product in at runtime. Therefore, we do not know during
development what the username will be. So I when developing our stored proc
s
we won't know how to prefix the function calls.
Does that clarify this at all?
DK
"Aaron Bertrand [SQL Server MVP]" wrote:

> Are you saying you have different functions for every user, with the same
> name? Yikes. Why not pass the USER_NAME() into the function and have the
> logic there, instead of having to maintain an object per user? Who is goi
ng
> to maintain these functions as users are added/removed?
>
> "Dwayne King" <dwayne.king@.cognos.com> wrote in message
> news:D905030B-4E3F-4543-93A4-E0EE1B95DC74@.microsoft.com...
>
>|||> Sorry - I haven't explained myself very well.
> There is only one user and one set of functions. The problem is, this is
> a
> product that our customer installs, and we allow them to choose what user
> to
> install the product in at runtime. Therefore, we do not know during
> development what the username will be. So I when developing our stored
> procs
> we won't know how to prefix the function calls.
> Does that clarify this at all?
Yes, that you are still confusing users and object owners.
My recommendation is to create all tables, procedures and functions with the
dbo. prefix, and to always use that prefix in the code.
A|||I'm more than willing to admit my ignorance of the difference. Most of my
experience is on Oracle :)
If we followed your suggestion of creating everything using the "dbo"
prefix, wouldn't the user be required to be the "dbowner"? The motivation
by mgmt was to allow the customer to install the product with a few
privileges as possible.
Sorry if I seem to be missing the point, but the differences in the SQL
Server concepts of login vs users never really made a lot of sense to me.
Thanks for your patience.
DK
"Aaron Bertrand [SQL Server MVP]" wrote:

> Yes, that you are still confusing users and object owners.
> My recommendation is to create all tables, procedures and functions with t
he
> dbo. prefix, and to always use that prefix in the code.
>|||> If we followed your suggestion of creating everything using the "dbo"
> prefix, wouldn't the user be required to be the "dbowner"?
NO. You need to grant users the right to execute stored procedures, etc.
The owner is not the only person who can see or use it.
This is a fairly common practice, and I see very few SQL 2000 installations
with even a single object owned by anyone but the explicit dbo.

> Sorry if I seem to be missing the point, but the differences in the SQL
> Server concepts of login vs users never really made a lot of sense to me.
Do you have Books Online? It may not be very exciting reading, but the
differences are laid out there.
A|||Wow.....nothing more humbling that learning a new database and it's
peculiarities :) Thanks for your patience.
I'm convinced there's some fundamental piece of information I'm still
missing. With the following trivial test case:
create table dbo.my_dbo_table (col1 varchar(10))
Neither of the following work because I'm missing SELECT privileges:
select * from my_dbo_table
select * from dbo.my_dbo_table
So I try:
grant select, insert, update,delete on dbo.my_dbo_table to jdbcuser
But that doesn't work, because I get "Grantor does not have GRANT
permission." So.......I'm allowed to create objects with dbo. but I then
retain no privileges on them, even though I created them?
Is the dbowner the only one allowed to grant privs on these objects?
DK
"Aaron Bertrand [SQL Server MVP]" wrote:

> NO. You need to grant users the right to execute stored procedures, etc.
> The owner is not the only person who can see or use it.
> This is a fairly common practice, and I see very few SQL 2000 installation
s
> with even a single object owned by anyone but the explicit dbo.
>
> Do you have Books Online? It may not be very exciting reading, but the
> differences are laid out there.|||> grant select, insert, update,delete on dbo.my_dbo_table to jdbcuser
> But that doesn't work, because I get "Grantor does not have GRANT
> permission." So.......I'm allowed to create objects with dbo. but I
> then
> retain no privileges on them, even though I created them?
> Is the dbowner the only one allowed to grant privs on these objects?
From the Books Online:
<Excerpt href="http://links.10026.com/?link=tsqlref.chm::/ts_ga-gz_8odw.htm">
The members of the symin role can grant any permissions in any database.
Object owners can grant permissions for the objects they own. Members of the
db_owner or db_securityadmin roles can grant any permissions on any
statement or object in their database.
</Excerpt>
I assume you are getting the error because none of the above apply. Since
you are able to create a dbo-owned object but not access it, it appears you
are a member of the db_ddladmin fixed database role. Members of that role
can create objects in any schema but that role membership doesn't
necessarily allow you to access or grant permissions on the created objects.
You won't run into this problem if you are also a member of the
db_securityadmin role but you might find it easier to run DDL scripts when
logged in as a symin role member or logged in as the database owner. In
both of these cases, your database security context will be the 'dbo' user
so all objects will be owned by 'dbo' by default. Alternatively, you can
run DDL as a db_owner role member but you will need to explicitly specify
'dbo' as the owner in order to create dbo-owned objects.
To add to what Aaron said, most SQL Server installations use dbo exclusively
for object ownership. This is because one can easily segregate dbo-owned
objects both logically and physically in the same SQL Server instance by
creating objects in different databases. 'dbo' will be used as the default
schema (when no like-named object is owned by the current user) so one
doesn't need to owner-qualify objects, except in the special case of UDFs.
although it is still a Best Practice to always owner-qualify objects.
It is probably best to stick with dbo-ownership if the target database is
dedicated to your application. BTW, the next version of SQL Server provides
a more clear distinction between owner and schema. I expect the dbo
ownership practice will lessen in SQL 2005.
Hope this helps.
Dan Guzman
SQL Server MVP
"Dwayne King" <dwayne.king@.cognos.com> wrote in message
news:9D159350-E5AB-4CA7-88BF-80FA427E3936@.microsoft.com...
> Wow.....nothing more humbling that learning a new database and it's
> peculiarities :) Thanks for your patience.
> I'm convinced there's some fundamental piece of information I'm still
> missing. With the following trivial test case:
> create table dbo.my_dbo_table (col1 varchar(10))
> Neither of the following work because I'm missing SELECT privileges:
> select * from my_dbo_table
> select * from dbo.my_dbo_table
> So I try:
> grant select, insert, update,delete on dbo.my_dbo_table to jdbcuser
> But that doesn't work, because I get "Grantor does not have GRANT
> permission." So.......I'm allowed to create objects with dbo. but I
> then
> retain no privileges on them, even though I created them?
> Is the dbowner the only one allowed to grant privs on these objects?
> --
> DK
>
> "Aaron Bertrand [SQL Server MVP]" wrote:
>
>sql

Question about referencing Full-Text noise file through SQL rowset functions.

(SQL Server 2000, SP3a)
Hello all!
I'm trying to cobble together something that will let me reference the "noise.eng" (the
English list of the Full Text Search service ignored words) through Transact-SQL.
I'm trying to reference the "noise.eng" file that's located in:
C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
There are a couple others in:
C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
C:\windows\SYSTEM32
but the one in the "Common Files" had the most recent date. :-)
I *have* had some measure of success with it -- but I'm trying to come up with a "cleaner"
way, if possible.
This is how I got this to work:
First I tried setting up a linked server:
--Create a linked server
execute [dbo].[sp_addlinkedserver]
'TextTest',
'Jet 4.0',
'Microsoft.Jet.OLEDB.4.0',
'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
NULL,
'Text'
go
--Set up login mappings
execute [dbo].[sp_addlinkedsrvlogin]
'TextTest',
FALSE,
NULL,
NULL
go
Then I checked out the tables that were available:
--List the tables in the linked server
execute [dbo].[sp_tables_ex] 'TextTest'
go
Interestingly, all the files in that directory with a .TXT extension were visible as
tables! However, the "noise.eng" file didn't seem to be available.
If I copied the "noise.eng" file to "noise.txt", then I could do something like:
select * from TextTest...[noise#txt]
or
select * from openquery(TextTest, 'select * from [noise#txt]') as a
And that seems to return the information! :-)
You can clean up the linked servers with:
execute [dbo].[sp_droplinkedsrvlogin]
'TextTest', NULL
go
execute [dbo].[sp_dropserver]
'TextTest'
go
However, I'd really like to use the OPENROWSET function if at all possible, and *not* have
to rename/copy the noise.eng file. I was reading that I could use a "schema.ini" file,
and after browsing the web, discovered this format that I thought might work:
[noise.eng]
ColNameHeader = False
CharacterSet = ANSI
Format = CSVDelimited
Col1=NoiseWord Char Width 100
Then I tried doing something like:
select *
from openrowset
(
'Microsoft.Jet.OLEDB.4.0',
'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
'select * from noise.eng'
) as a
Which doesn't quite work -- nor have any of the OPENROWSET variants I've tried. :-(
I'd like to be able to use OPENROWSET so that I don't have to create a linked server. I'd
also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to drop in
a "schema.ini" (if that's even necessary/helpful) in that directory.
I've found the following URLs to be useful sources of information:
http://groups.google.com/groups?q=sc...NGP10& rnum=6
http://groups.google.com/groups?q=sc...gle.com&rnum=2
Sorry for the length of this post, but I sure would be grateful to anyone who might be
able to help! :-)
John Peterson
I think I've been able to get close with some of this:
select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver (*.txt; *.csv)};
DefaultDir=C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config\;', 'select
* from noise.txt')
However, this seems to treat the first row as a header row.
select * from openrowset('Microsoft.Jet.OLEDB.4.0','Text;Databas e=C:\Program Files\Common
Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from noise.txt')
This is the closest I found, and allows me to specify that there is no header row.
The only remaining nit is that I *must* have an extension of .TXT. If I try to change
"noise.txt" to "noise.eng", I get errors.
A colleague of mine discovered that the JET driver has a list of "allowable" extensions:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engi nes\Text\Extensions
My guess is that if I put ".ENG" in that list, then the above queries will work with
"noise.eng". I was hoping to avoid modifying the Registry, though.
Does anyone know of a way to circumvent this issue?
Thanks!
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello all!
> I'm trying to cobble together something that will let me reference the "noise.eng" (the
> English list of the Full Text Search service ignored words) through Transact-SQL.
> I'm trying to reference the "noise.eng" file that's located in:
> C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> There are a couple others in:
> C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> C:\windows\SYSTEM32
> but the one in the "Common Files" had the most recent date. :-)
> I *have* had some measure of success with it -- but I'm trying to come up with a
"cleaner"
> way, if possible.
> This is how I got this to work:
> First I tried setting up a linked server:
> --Create a linked server
> execute [dbo].[sp_addlinkedserver]
> 'TextTest',
> 'Jet 4.0',
> 'Microsoft.Jet.OLEDB.4.0',
> 'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
> NULL,
> 'Text'
> go
> --Set up login mappings
> execute [dbo].[sp_addlinkedsrvlogin]
> 'TextTest',
> FALSE,
> NULL,
> NULL
> go
> Then I checked out the tables that were available:
> --List the tables in the linked server
> execute [dbo].[sp_tables_ex] 'TextTest'
> go
> Interestingly, all the files in that directory with a .TXT extension were visible as
> tables! However, the "noise.eng" file didn't seem to be available.
> If I copied the "noise.eng" file to "noise.txt", then I could do something like:
> select * from TextTest...[noise#txt]
> or
> select * from openquery(TextTest, 'select * from [noise#txt]') as a
> And that seems to return the information! :-)
> You can clean up the linked servers with:
> execute [dbo].[sp_droplinkedsrvlogin]
> 'TextTest', NULL
> go
> execute [dbo].[sp_dropserver]
> 'TextTest'
> go
> However, I'd really like to use the OPENROWSET function if at all possible, and *not*
have
> to rename/copy the noise.eng file. I was reading that I could use a "schema.ini" file,
> and after browsing the web, discovered this format that I thought might work:
> [noise.eng]
> ColNameHeader = False
> CharacterSet = ANSI
> Format = CSVDelimited
> Col1=NoiseWord Char Width 100
> Then I tried doing something like:
> select *
> from openrowset
> (
> 'Microsoft.Jet.OLEDB.4.0',
> 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\Microsoft
> Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
> 'select * from noise.eng'
> ) as a
> Which doesn't quite work -- nor have any of the OPENROWSET variants I've tried. :-(
> I'd like to be able to use OPENROWSET so that I don't have to create a linked server.
I'd
> also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to drop
in
> a "schema.ini" (if that's even necessary/helpful) in that directory.
> I've found the following URLs to be useful sources of information:
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
> Sorry for the length of this post, but I sure would be grateful to anyone who might be
> able to help! :-)
> John Peterson
>
|||John,
A most interesting solution! You would need to use ".ENU" in that list, then
the above queries will work with "noise.enu" (US_English). Can I assume
you've tried to import the noise word file into a table? For example:
CREATE TABLE sqlfts_stop_words (
term nvarchar(50) NOT NULL )
GO
ALTER TABLE sqlfts_stop_words ADD
CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
GO
-- Alter drive letter and path to noise.enu as appropriate
BULK INSERT sqlfts_stop_words FROM
'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.en u'
GO
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> I think I've been able to get close with some of this:
> select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
(*.txt; *.csv)};
> DefaultDir=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config\;', 'select
> * from noise.txt')
> However, this seems to treat the first row as a header row.
> select * from
openrowset('Microsoft.Jet.OLEDB.4.0','Text;Databas e=C:\Program Files\Common
> Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
noise.txt')
> This is the closest I found, and allows me to specify that there is no
header row.
> The only remaining nit is that I *must* have an extension of .TXT. If I
try to change
> "noise.txt" to "noise.eng", I get errors.
> A colleague of mine discovered that the JET driver has a list of
"allowable" extensions:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engi nes\Text\Extensions
> My guess is that if I put ".ENG" in that list, then the above queries will
work with[vbcol=seagreen]
> "noise.eng". I was hoping to avoid modifying the Registry, though.
> Does anyone know of a way to circumvent this issue?
> Thanks!
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
"noise.eng" (the[vbcol=seagreen]
Transact-SQL.[vbcol=seagreen]
up with a[vbcol=seagreen]
> "cleaner"
Shared\MSSearch\Data\Config',[vbcol=seagreen]
were visible as[vbcol=seagreen]
something like:[vbcol=seagreen]
possible, and *not*[vbcol=seagreen]
> have
"schema.ini" file,[vbcol=seagreen]
work:[vbcol=seagreen]
Files\Microsoft[vbcol=seagreen]
tried. :-([vbcol=seagreen]
linked server.[vbcol=seagreen]
> I'd
having to drop
> in
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2[vbcol=seagreen]
anyone who might be
>
|||Hello John!
I was finally able to come up with a couple of solutions with the OPENQUERY, and settled
on the Registry "dink" for the various "noise.*" extensions. (My other technique was to
copy the specified noise file to a temporary file with a ".TXT" extension, but that was
using [xp_cmdshell] and our users aren't members of the db_admin role and I was leery of
opening up the permissions on that procedure.)
Your option to populate a table with the noise words is intriguing, too. We don't change
the noise list too often, but we *do* add stuff to it on occasion. I wonder if I could
have a scheduled Job that would essentially keep the file in sync with the table every
week or so? Something like that might work better.
Our application will be caching the results of the OPENQUERY approach -- so I don't feel
too bad about the potential "hit" for reading the file every time the SP is invoked. But
it is more "clumsy" than just having a static table...
Thanks for the alternative suggestion -- I'll have to mull it over further! :-)
"John Kane" <jt-kane@.comcast.net> wrote in message
news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> John,
> A most interesting solution! You would need to use ".ENU" in that list, then
> the above queries will work with "noise.enu" (US_English). Can I assume
> you've tried to import the noise word file into a table? For example:
> CREATE TABLE sqlfts_stop_words (
> term nvarchar(50) NOT NULL )
> GO
> ALTER TABLE sqlfts_stop_words ADD
> CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> GO
> -- Alter drive letter and path to noise.enu as appropriate
> BULK INSERT sqlfts_stop_words FROM
> 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.en u'
> GO
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> (*.txt; *.csv)};
> Shared\MSSearch\Data\Config\;', 'select
> openrowset('Microsoft.Jet.OLEDB.4.0','Text;Databas e=C:\Program Files\Common
> noise.txt')
> header row.
> try to change
> "allowable" extensions:
> work with
> "noise.eng" (the
> Transact-SQL.
> up with a
> Shared\MSSearch\Data\Config',
> were visible as
> something like:
> possible, and *not*
> "schema.ini" file,
> work:
> Files\Microsoft
> tried. :-(
> linked server.
> having to drop
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
> anyone who might be
>
|||Hi John,
When you need to change the noise word file, you can setup a SQLServerAgent
job to BCP out to a noise.tmp text file, then stop the MSSearch service,
swap out the files and restart the MSSearch service and then run a Full
Population. You can make this as simple or as complex as you need. Also, for
the below BULK INSERT to work without errors, you will need to manually edit
the noise.enu file and place CR/LF after each single letter at the end of
the file, for example:
a b c d...
becomes
a
b
c
d...
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> Hello John!
> I was finally able to come up with a couple of solutions with the
OPENQUERY, and settled
> on the Registry "dink" for the various "noise.*" extensions. (My other
technique was to
> copy the specified noise file to a temporary file with a ".TXT" extension,
but that was
> using [xp_cmdshell] and our users aren't members of the db_admin role and
I was leery of
> opening up the permissions on that procedure.)
> Your option to populate a table with the noise words is intriguing, too.
We don't change
> the noise list too often, but we *do* add stuff to it on occasion. I
wonder if I could
> have a scheduled Job that would essentially keep the file in sync with the
table every
> week or so? Something like that might work better.
> Our application will be caching the results of the OPENQUERY approach --
so I don't feel
> too bad about the potential "hit" for reading the file every time the SP
is invoked. But
> it is more "clumsy" than just having a static table...
> Thanks for the alternative suggestion -- I'll have to mull it over
further! :-)[vbcol=seagreen]
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
then[vbcol=seagreen]
Files\Common[vbcol=seagreen]
I[vbcol=seagreen]
will[vbcol=seagreen]
the[vbcol=seagreen]
come[vbcol=seagreen]
might[vbcol=seagreen]
Files\Common[vbcol=seagreen]
Properties="text;HDR=No;FMT=CSV";',[vbcol=seagreen]
I've[vbcol=seagreen]
a[vbcol=seagreen]
mind
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
>
|||Thanks John!
I notice that there's a line in the noise.enu file that is:
a b c d e ... x y z
I'm assuming that "word" is really a space-delimited list of single noise words? If I
leave that "as is", will that be a problem? Or is there something with the mechanics of
the BULK INSERT that will give me problems with that? I can easily "parse" those values
out into the "expanded list", so I don't mind leaving it the way it is, unless it hoses up
the BULK INSERT.
Can I also assume, then, that I could potentially put other multiple noise words on the
same line, separated by a space if I wanted to? What if I wanted a *phrase* to be ignored
that contained spaces?
Thanks again for your help!
John Peterson
"John Kane" <jt-kane@.comcast.net> wrote in message
news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
> Hi John,
> When you need to change the noise word file, you can setup a SQLServerAgent
> job to BCP out to a noise.tmp text file, then stop the MSSearch service,
> swap out the files and restart the MSSearch service and then run a Full
> Population. You can make this as simple or as complex as you need. Also, for
> the below BULK INSERT to work without errors, you will need to manually edit
> the noise.enu file and place CR/LF after each single letter at the end of
> the file, for example:
> a b c d...
> becomes
> a
> b
> c
> d...
> Regards,
> John
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> OPENQUERY, and settled
> technique was to
> but that was
> I was leery of
> We don't change
> wonder if I could
> table every
> so I don't feel
> is invoked. But
> further! :-)
> then
> Files\Common
> I
> will
> the
> come
> might
> Files\Common
> Properties="text;HDR=No;FMT=CSV";',
> I've
> a
> mind
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
>
|||Yes, that's the line I'm referring to... Yes, if you leave it "as is" it
will cause the BULK INSERT to throw an error and the single letters will not
be imported. However, making the change does not affect MSSearch, it's just
that the bulk insert hick-ups with the spaces between the single letters.
No, your assumption is incorrect (I've already tried that years ago ;-) and
the multiple-word noise phrases are ignored by MSSearch.
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#f1$$R#MEHA.3972@.TK2MSFTNGP10.phx.gbl...
> Thanks John!
> I notice that there's a line in the noise.enu file that is:
> a b c d e ... x y z
> I'm assuming that "word" is really a space-delimited list of single noise
words? If I
> leave that "as is", will that be a problem? Or is there something with
the mechanics of
> the BULK INSERT that will give me problems with that? I can easily
"parse" those values
> out into the "expanded list", so I don't mind leaving it the way it is,
unless it hoses up
> the BULK INSERT.
> Can I also assume, then, that I could potentially put other multiple noise
words on the
> same line, separated by a space if I wanted to? What if I wanted a
*phrase* to be ignored[vbcol=seagreen]
> that contained spaces?
> Thanks again for your help!
> John Peterson
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
SQLServerAgent[vbcol=seagreen]
for[vbcol=seagreen]
edit[vbcol=seagreen]
of[vbcol=seagreen]
other[vbcol=seagreen]
extension,[vbcol=seagreen]
and[vbcol=seagreen]
too.[vbcol=seagreen]
the[vbcol=seagreen]
approach --[vbcol=seagreen]
SP[vbcol=seagreen]
list,[vbcol=seagreen]
assume[vbcol=seagreen]
example:[vbcol=seagreen]
Driver[vbcol=seagreen]
from[vbcol=seagreen]
is no[vbcol=seagreen]
If[vbcol=seagreen]
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engi nes\Text\Extensions[vbcol=seagreen]
queries[vbcol=seagreen]
though.[vbcol=seagreen]
reference[vbcol=seagreen]
through[vbcol=seagreen]
Shared\MSSearch\Data\Config[vbcol=seagreen]
Server\MSSQL\FTDATA\SQLServer\Config[vbcol=seagreen]
to[vbcol=seagreen]
extension[vbcol=seagreen]
available.[vbcol=seagreen]
as a[vbcol=seagreen]
all[vbcol=seagreen]
use a[vbcol=seagreen]
thought[vbcol=seagreen]
variants[vbcol=seagreen]
create[vbcol=seagreen]
don't[vbcol=seagreen]
directory.[vbcol=seagreen]
information:
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2[vbcol=seagreen]
to
>

Question about referencing Full-Text noise file through SQL rowset functions.

(SQL Server 2000, SP3a)
Hello all!
I'm trying to cobble together something that will let me reference the "noise.eng" (the
English list of the Full Text Search service ignored words) through Transact-SQL.
I'm trying to reference the "noise.eng" file that's located in:
C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
There are a couple others in:
C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
C:\windows\SYSTEM32
but the one in the "Common Files" had the most recent date. :-)
I *have* had some measure of success with it -- but I'm trying to come up with a "cleaner"
way, if possible.
This is how I got this to work:
First I tried setting up a linked server:
--Create a linked server
execute [dbo].[sp_addlinkedserver]
'TextTest',
'Jet 4.0',
'Microsoft.Jet.OLEDB.4.0',
'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
NULL,
'Text'
go
--Set up login mappings
execute [dbo].[sp_addlinkedsrvlogin]
'TextTest',
FALSE,
NULL,
NULL
go
Then I checked out the tables that were available:
--List the tables in the linked server
execute [dbo].[sp_tables_ex] 'TextTest'
go
Interestingly, all the files in that directory with a .TXT extension were visible as
tables! However, the "noise.eng" file didn't seem to be available.
If I copied the "noise.eng" file to "noise.txt", then I could do something like:
select * from TextTest...[noise#txt]
or
select * from openquery(TextTest, 'select * from [noise#txt]') as a
And that seems to return the information! :-)
You can clean up the linked servers with:
execute [dbo].[sp_droplinkedsrvlogin]
'TextTest', NULL
go
execute [dbo].[sp_dropserver]
'TextTest'
go
However, I'd really like to use the OPENROWSET function if at all possible, and *not* have
to rename/copy the noise.eng file. I was reading that I could use a "schema.ini" file,
and after browsing the web, discovered this format that I thought might work:
[noise.eng]
ColNameHeader = False
CharacterSet = ANSI
Format = CSVDelimited
Col1=NoiseWord Char Width 100
Then I tried doing something like:
select *
from openrowset
(
'Microsoft.Jet.OLEDB.4.0',
'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
'select * from noise.eng'
) as a
Which doesn't quite work -- nor have any of the OPENROWSET variants I've tried. :-(
I'd like to be able to use OPENROWSET so that I don't have to create a linked server. I'd
also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to drop in
a "schema.ini" (if that's even necessary/helpful) in that directory.
I've found the following URLs to be useful sources of information:
http://groups.google.com/groups?q=sc...NGP10& rnum=6
http://groups.google.com/groups?q=sc...gle.com&rnum=2
Sorry for the length of this post, but I sure would be grateful to anyone who might be
able to help! :-)
John Peterson
I think I've been able to get close with some of this:
select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver (*.txt; *.csv)};
DefaultDir=C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config\;', 'select
* from noise.txt')
However, this seems to treat the first row as a header row.
select * from openrowset('Microsoft.Jet.OLEDB.4.0','Text;Databas e=C:\Program Files\Common
Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from noise.txt')
This is the closest I found, and allows me to specify that there is no header row.
The only remaining nit is that I *must* have an extension of .TXT. If I try to change
"noise.txt" to "noise.eng", I get errors.
A colleague of mine discovered that the JET driver has a list of "allowable" extensions:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engi nes\Text\Extensions
My guess is that if I put ".ENG" in that list, then the above queries will work with
"noise.eng". I was hoping to avoid modifying the Registry, though.
Does anyone know of a way to circumvent this issue?
Thanks!
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello all!
> I'm trying to cobble together something that will let me reference the "noise.eng" (the
> English list of the Full Text Search service ignored words) through Transact-SQL.
> I'm trying to reference the "noise.eng" file that's located in:
> C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> There are a couple others in:
> C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> C:\windows\SYSTEM32
> but the one in the "Common Files" had the most recent date. :-)
> I *have* had some measure of success with it -- but I'm trying to come up with a
"cleaner"
> way, if possible.
> This is how I got this to work:
> First I tried setting up a linked server:
> --Create a linked server
> execute [dbo].[sp_addlinkedserver]
> 'TextTest',
> 'Jet 4.0',
> 'Microsoft.Jet.OLEDB.4.0',
> 'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
> NULL,
> 'Text'
> go
> --Set up login mappings
> execute [dbo].[sp_addlinkedsrvlogin]
> 'TextTest',
> FALSE,
> NULL,
> NULL
> go
> Then I checked out the tables that were available:
> --List the tables in the linked server
> execute [dbo].[sp_tables_ex] 'TextTest'
> go
> Interestingly, all the files in that directory with a .TXT extension were visible as
> tables! However, the "noise.eng" file didn't seem to be available.
> If I copied the "noise.eng" file to "noise.txt", then I could do something like:
> select * from TextTest...[noise#txt]
> or
> select * from openquery(TextTest, 'select * from [noise#txt]') as a
> And that seems to return the information! :-)
> You can clean up the linked servers with:
> execute [dbo].[sp_droplinkedsrvlogin]
> 'TextTest', NULL
> go
> execute [dbo].[sp_dropserver]
> 'TextTest'
> go
> However, I'd really like to use the OPENROWSET function if at all possible, and *not*
have
> to rename/copy the noise.eng file. I was reading that I could use a "schema.ini" file,
> and after browsing the web, discovered this format that I thought might work:
> [noise.eng]
> ColNameHeader = False
> CharacterSet = ANSI
> Format = CSVDelimited
> Col1=NoiseWord Char Width 100
> Then I tried doing something like:
> select *
> from openrowset
> (
> 'Microsoft.Jet.OLEDB.4.0',
> 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\Microsoft
> Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
> 'select * from noise.eng'
> ) as a
> Which doesn't quite work -- nor have any of the OPENROWSET variants I've tried. :-(
> I'd like to be able to use OPENROWSET so that I don't have to create a linked server.
I'd
> also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to drop
in
> a "schema.ini" (if that's even necessary/helpful) in that directory.
> I've found the following URLs to be useful sources of information:
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
> Sorry for the length of this post, but I sure would be grateful to anyone who might be
> able to help! :-)
> John Peterson
>
|||John,
A most interesting solution! You would need to use ".ENU" in that list, then
the above queries will work with "noise.enu" (US_English). Can I assume
you've tried to import the noise word file into a table? For example:
CREATE TABLE sqlfts_stop_words (
term nvarchar(50) NOT NULL )
GO
ALTER TABLE sqlfts_stop_words ADD
CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
GO
-- Alter drive letter and path to noise.enu as appropriate
BULK INSERT sqlfts_stop_words FROM
'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.en u'
GO
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> I think I've been able to get close with some of this:
> select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
(*.txt; *.csv)};
> DefaultDir=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config\;', 'select
> * from noise.txt')
> However, this seems to treat the first row as a header row.
> select * from
openrowset('Microsoft.Jet.OLEDB.4.0','Text;Databas e=C:\Program Files\Common
> Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
noise.txt')
> This is the closest I found, and allows me to specify that there is no
header row.
> The only remaining nit is that I *must* have an extension of .TXT. If I
try to change
> "noise.txt" to "noise.eng", I get errors.
> A colleague of mine discovered that the JET driver has a list of
"allowable" extensions:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engi nes\Text\Extensions
> My guess is that if I put ".ENG" in that list, then the above queries will
work with[vbcol=seagreen]
> "noise.eng". I was hoping to avoid modifying the Registry, though.
> Does anyone know of a way to circumvent this issue?
> Thanks!
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
"noise.eng" (the[vbcol=seagreen]
Transact-SQL.[vbcol=seagreen]
up with a[vbcol=seagreen]
> "cleaner"
Shared\MSSearch\Data\Config',[vbcol=seagreen]
were visible as[vbcol=seagreen]
something like:[vbcol=seagreen]
possible, and *not*[vbcol=seagreen]
> have
"schema.ini" file,[vbcol=seagreen]
work:[vbcol=seagreen]
Files\Microsoft[vbcol=seagreen]
tried. :-([vbcol=seagreen]
linked server.[vbcol=seagreen]
> I'd
having to drop
> in
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2[vbcol=seagreen]
anyone who might be
>
|||Hello John!
I was finally able to come up with a couple of solutions with the OPENQUERY, and settled
on the Registry "dink" for the various "noise.*" extensions. (My other technique was to
copy the specified noise file to a temporary file with a ".TXT" extension, but that was
using [xp_cmdshell] and our users aren't members of the db_admin role and I was leery of
opening up the permissions on that procedure.)
Your option to populate a table with the noise words is intriguing, too. We don't change
the noise list too often, but we *do* add stuff to it on occasion. I wonder if I could
have a scheduled Job that would essentially keep the file in sync with the table every
week or so? Something like that might work better.
Our application will be caching the results of the OPENQUERY approach -- so I don't feel
too bad about the potential "hit" for reading the file every time the SP is invoked. But
it is more "clumsy" than just having a static table...
Thanks for the alternative suggestion -- I'll have to mull it over further! :-)
"John Kane" <jt-kane@.comcast.net> wrote in message
news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> John,
> A most interesting solution! You would need to use ".ENU" in that list, then
> the above queries will work with "noise.enu" (US_English). Can I assume
> you've tried to import the noise word file into a table? For example:
> CREATE TABLE sqlfts_stop_words (
> term nvarchar(50) NOT NULL )
> GO
> ALTER TABLE sqlfts_stop_words ADD
> CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> GO
> -- Alter drive letter and path to noise.enu as appropriate
> BULK INSERT sqlfts_stop_words FROM
> 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.en u'
> GO
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> (*.txt; *.csv)};
> Shared\MSSearch\Data\Config\;', 'select
> openrowset('Microsoft.Jet.OLEDB.4.0','Text;Databas e=C:\Program Files\Common
> noise.txt')
> header row.
> try to change
> "allowable" extensions:
> work with
> "noise.eng" (the
> Transact-SQL.
> up with a
> Shared\MSSearch\Data\Config',
> were visible as
> something like:
> possible, and *not*
> "schema.ini" file,
> work:
> Files\Microsoft
> tried. :-(
> linked server.
> having to drop
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
> anyone who might be
>
|||Hi John,
When you need to change the noise word file, you can setup a SQLServerAgent
job to BCP out to a noise.tmp text file, then stop the MSSearch service,
swap out the files and restart the MSSearch service and then run a Full
Population. You can make this as simple or as complex as you need. Also, for
the below BULK INSERT to work without errors, you will need to manually edit
the noise.enu file and place CR/LF after each single letter at the end of
the file, for example:
a b c d...
becomes
a
b
c
d...
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> Hello John!
> I was finally able to come up with a couple of solutions with the
OPENQUERY, and settled
> on the Registry "dink" for the various "noise.*" extensions. (My other
technique was to
> copy the specified noise file to a temporary file with a ".TXT" extension,
but that was
> using [xp_cmdshell] and our users aren't members of the db_admin role and
I was leery of
> opening up the permissions on that procedure.)
> Your option to populate a table with the noise words is intriguing, too.
We don't change
> the noise list too often, but we *do* add stuff to it on occasion. I
wonder if I could
> have a scheduled Job that would essentially keep the file in sync with the
table every
> week or so? Something like that might work better.
> Our application will be caching the results of the OPENQUERY approach --
so I don't feel
> too bad about the potential "hit" for reading the file every time the SP
is invoked. But
> it is more "clumsy" than just having a static table...
> Thanks for the alternative suggestion -- I'll have to mull it over
further! :-)[vbcol=seagreen]
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
then[vbcol=seagreen]
Files\Common[vbcol=seagreen]
I[vbcol=seagreen]
will[vbcol=seagreen]
the[vbcol=seagreen]
come[vbcol=seagreen]
might[vbcol=seagreen]
Files\Common[vbcol=seagreen]
Properties="text;HDR=No;FMT=CSV";',[vbcol=seagreen]
I've[vbcol=seagreen]
a[vbcol=seagreen]
mind
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
>
|||Thanks John!
I notice that there's a line in the noise.enu file that is:
a b c d e ... x y z
I'm assuming that "word" is really a space-delimited list of single noise words? If I
leave that "as is", will that be a problem? Or is there something with the mechanics of
the BULK INSERT that will give me problems with that? I can easily "parse" those values
out into the "expanded list", so I don't mind leaving it the way it is, unless it hoses up
the BULK INSERT.
Can I also assume, then, that I could potentially put other multiple noise words on the
same line, separated by a space if I wanted to? What if I wanted a *phrase* to be ignored
that contained spaces?
Thanks again for your help!
John Peterson
"John Kane" <jt-kane@.comcast.net> wrote in message
news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
> Hi John,
> When you need to change the noise word file, you can setup a SQLServerAgent
> job to BCP out to a noise.tmp text file, then stop the MSSearch service,
> swap out the files and restart the MSSearch service and then run a Full
> Population. You can make this as simple or as complex as you need. Also, for
> the below BULK INSERT to work without errors, you will need to manually edit
> the noise.enu file and place CR/LF after each single letter at the end of
> the file, for example:
> a b c d...
> becomes
> a
> b
> c
> d...
> Regards,
> John
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> OPENQUERY, and settled
> technique was to
> but that was
> I was leery of
> We don't change
> wonder if I could
> table every
> so I don't feel
> is invoked. But
> further! :-)
> then
> Files\Common
> I
> will
> the
> come
> might
> Files\Common
> Properties="text;HDR=No;FMT=CSV";',
> I've
> a
> mind
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2
>
|||Yes, that's the line I'm referring to... Yes, if you leave it "as is" it
will cause the BULK INSERT to throw an error and the single letters will not
be imported. However, making the change does not affect MSSearch, it's just
that the bulk insert hick-ups with the spaces between the single letters.
No, your assumption is incorrect (I've already tried that years ago ;-) and
the multiple-word noise phrases are ignored by MSSearch.
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#f1$$R#MEHA.3972@.TK2MSFTNGP10.phx.gbl...
> Thanks John!
> I notice that there's a line in the noise.enu file that is:
> a b c d e ... x y z
> I'm assuming that "word" is really a space-delimited list of single noise
words? If I
> leave that "as is", will that be a problem? Or is there something with
the mechanics of
> the BULK INSERT that will give me problems with that? I can easily
"parse" those values
> out into the "expanded list", so I don't mind leaving it the way it is,
unless it hoses up
> the BULK INSERT.
> Can I also assume, then, that I could potentially put other multiple noise
words on the
> same line, separated by a space if I wanted to? What if I wanted a
*phrase* to be ignored[vbcol=seagreen]
> that contained spaces?
> Thanks again for your help!
> John Peterson
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
SQLServerAgent[vbcol=seagreen]
for[vbcol=seagreen]
edit[vbcol=seagreen]
of[vbcol=seagreen]
other[vbcol=seagreen]
extension,[vbcol=seagreen]
and[vbcol=seagreen]
too.[vbcol=seagreen]
the[vbcol=seagreen]
approach --[vbcol=seagreen]
SP[vbcol=seagreen]
list,[vbcol=seagreen]
assume[vbcol=seagreen]
example:[vbcol=seagreen]
Driver[vbcol=seagreen]
from[vbcol=seagreen]
is no[vbcol=seagreen]
If[vbcol=seagreen]
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engi nes\Text\Extensions[vbcol=seagreen]
queries[vbcol=seagreen]
though.[vbcol=seagreen]
reference[vbcol=seagreen]
through[vbcol=seagreen]
Shared\MSSearch\Data\Config[vbcol=seagreen]
Server\MSSQL\FTDATA\SQLServer\Config[vbcol=seagreen]
to[vbcol=seagreen]
extension[vbcol=seagreen]
available.[vbcol=seagreen]
as a[vbcol=seagreen]
all[vbcol=seagreen]
use a[vbcol=seagreen]
thought[vbcol=seagreen]
variants[vbcol=seagreen]
create[vbcol=seagreen]
don't[vbcol=seagreen]
directory.[vbcol=seagreen]
information:
>
http://groups.google.com/groups?q=sc...NGP10& rnum=6
>
http://groups.google.com/groups?q=sc...gle.com&rnum=2[vbcol=seagreen]
to
>

Question about referencing Full-Text noise file through SQL rowset functions.

(SQL Server 2000, SP3a)
Hello all!
I'm trying to cobble together something that will let me reference the "nois
e.eng" (the
English list of the Full Text Search service ignored words) through Transact
-SQL.
I'm trying to reference the "noise.eng" file that's located in:
C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
There are a couple others in:
C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
C:\windows\SYSTEM32
but the one in the "Common Files" had the most recent date. :-)
I *have* had some measure of success with it -- but I'm trying to come up wi
th a "cleaner"
way, if possible.
This is how I got this to work:
First I tried setting up a linked server:
--Create a linked server
execute [dbo].[sp_addlinkedserver]
'TextTest',
'Jet 4.0',
'Microsoft.Jet.OLEDB.4.0',
'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
NULL,
'Text'
go
--Set up login mappings
execute [dbo].[sp_addlinkedsrvlogin]
'TextTest',
FALSE,
NULL,
NULL
go
Then I checked out the tables that were available:
--List the tables in the linked server
execute [dbo].[sp_tables_ex] 'TextTest'
go
Interestingly, all the files in that directory with a .TXT extension were vi
sible as
tables! However, the "noise.eng" file didn't seem to be available.
If I copied the "noise.eng" file to "noise.txt", then I could do something l
ike:
select * from TextTest...[noise#txt]
or
select * from openquery(TextTest, 'select * from [noise#txt]') as a
And that seems to return the information! :-)
You can clean up the linked servers with:
execute [dbo].[sp_droplinkedsrvlogin]
'TextTest', NULL
go
execute [dbo].[sp_dropserver]
'TextTest'
go
However, I'd really like to use the OPENROWSET function if at all possible,
and *not* have
to rename/copy the noise.eng file. I was reading that I could use a "schema
.ini" file,
and after browsing the web, discovered this format that I thought might work
:
[noise.eng]
ColNameHeader = False
CharacterSet = ANSI
Format = CSVDelimited
Col1=NoiseWord Char Width 100
Then I tried doing something like:
select *
from openrowset
(
'Microsoft.Jet.OLEDB.4.0',
'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\
Microsoft
Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
'select * from noise.eng'
) as a
Which doesn't quite work -- nor have any of the OPENROWSET variants I've tri
ed. :-(
I'd like to be able to use OPENROWSET so that I don't have to create a linke
d server. I'd
also like to avoid copying the "noise.eng" to "noise.txt". I don't mind hav
ing to drop in
a "schema.ini" (if that's even necessary/helpful) in that directory.
I've found the following URLs to be useful sources of information:
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
http://groups.google.com/groups?q=s...ogle.com&rnum=2
Sorry for the length of this post, but I sure would be grateful to anyone wh
o might be
able to help! :-)
John PetersonI think I've been able to get close with some of this:
select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver (*
.txt; *.csv)};
DefaultDir=C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Conf
ig\;', 'select
* from noise.txt')
However, this seems to treat the first row as a header row.
select * from openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program
Files\Common
Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from noise.t
xt')
This is the closest I found, and allows me to specify that there is no heade
r row.
The only remaining nit is that I *must* have an extension of .TXT. If I try
to change
"noise.txt" to "noise.eng", I get errors.
A colleague of mine discovered that the JET driver has a list of "allowable"
extensions:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Je
t\4.0\Engines\Text\Extensions
My guess is that if I put ".ENG" in that list, then the above queries will w
ork with
"noise.eng". I was hoping to avoid modifying the Registry, though.
Does anyone know of a way to circumvent this issue?
Thanks!
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello all!
> I'm trying to cobble together something that will let me reference the "no
ise.eng" (the
> English list of the Full Text Search service ignored words) through Transa
ct-SQL.
> I'm trying to reference the "noise.eng" file that's located in:
> C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> There are a couple others in:
> C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> C:\windows\SYSTEM32
> but the one in the "Common Files" had the most recent date. :-)
> I *have* had some measure of success with it -- but I'm trying to come up with a[/
vbcol]
"cleaner"[vbcol=seagreen]
> way, if possible.
> This is how I got this to work:
> First I tried setting up a linked server:
> --Create a linked server
> execute [dbo].[sp_addlinkedserver]
> 'TextTest',
> 'Jet 4.0',
> 'Microsoft.Jet.OLEDB.4.0',
> 'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
> NULL,
> 'Text'
> go
> --Set up login mappings
> execute [dbo].[sp_addlinkedsrvlogin]
> 'TextTest',
> FALSE,
> NULL,
> NULL
> go
> Then I checked out the tables that were available:
> --List the tables in the linked server
> execute [dbo].[sp_tables_ex] 'TextTest'
> go
> Interestingly, all the files in that directory with a .TXT extension were
visible as
> tables! However, the "noise.eng" file didn't seem to be available.
> If I copied the "noise.eng" file to "noise.txt", then I could do something
like:
> select * from TextTest...[noise#txt]
> or
> select * from openquery(TextTest, 'select * from [noise#txt]') as a
> And that seems to return the information! :-)
> You can clean up the linked servers with:
> execute [dbo].[sp_droplinkedsrvlogin]
> 'TextTest', NULL
> go
> execute [dbo].[sp_dropserver]
> 'TextTest'
> go
> However, I'd really like to use the OPENROWSET function if at all possible, and *n
ot*
have
> to rename/copy the noise.eng file. I was reading that I could use a "sche
ma.ini" file,
> and after browsing the web, discovered this format that I thought might wo
rk:
> [noise.eng]
> ColNameHeader = False
> CharacterSet = ANSI
> Format = CSVDelimited
> Col1=NoiseWord Char Width 100
> Then I tried doing something like:
> select *
> from openrowset
> (
> 'Microsoft.Jet.OLEDB.4.0',
> 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common F
iles\Microsoft
> Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
> 'select * from noise.eng'
> ) as a
> Which doesn't quite work -- nor have any of the OPENROWSET variants I've t
ried. :-(
> I'd like to be able to use OPENROWSET so that I don't have to create a linked serv
er.
I'd
> also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to
drop
in
> a "schema.ini" (if that's even necessary/helpful) in that directory.
> I've found the following URLs to be useful sources of information:
>
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
>
http://groups.google.com/groups?q=s...ogle.com&rnum=2
> Sorry for the length of this post, but I sure would be grateful to anyone
who might be
> able to help! :-)
> John Peterson
>|||John,
A most interesting solution! You would need to use ".ENU" in that list, then
the above queries will work with "noise.enu" (US_English). Can I assume
you've tried to import the noise word file into a table? For example:
CREATE TABLE sqlfts_stop_words (
term nvarchar(50) NOT NULL )
GO
ALTER TABLE sqlfts_stop_words ADD
CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
GO
-- Alter drive letter and path to noise.enu as appropriate
BULK INSERT sqlfts_stop_words FROM
'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Confi
g\noise.enu'
GO
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> I think I've been able to get close with some of this:
> select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
(*.txt; *.csv)};
> DefaultDir=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config\;', 'select
> * from noise.txt')
> However, this seems to treat the first row as a header row.
> select * from
openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program Files\Common
> Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
noise.txt')
> This is the closest I found, and allows me to specify that there is no
header row.
> The only remaining nit is that I *must* have an extension of .TXT. If I
try to change
> "noise.txt" to "noise.eng", I get errors.
> A colleague of mine discovered that the JET driver has a list of
"allowable" extensions:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Je
t\4.0\Engines\Text\Extensions
> My guess is that if I put ".ENG" in that list, then the above queries will
work with
> "noise.eng". I was hoping to avoid modifying the Registry, though.
> Does anyone know of a way to circumvent this issue?
> Thanks!
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
"noise.eng" (the[vbcol=seagreen]
Transact-SQL.[vbcol=seagreen]
up with a[vbcol=seagreen]
> "cleaner"
Shared\MSSearch\Data\Config',[vbcol=seag
reen]
were visible as[vbcol=seagreen]
something like:[vbcol=seagreen]
possible, and *not*[vbcol=seagreen]
> have
"schema.ini" file,[vbcol=seagreen]
work:[vbcol=seagreen]
Files\Microsoft[vbcol=seagreen]
tried. :-([vbcol=seagreen]
linked server.[vbcol=seagreen]
> I'd
having to drop[vbcol=seagreen]
> in
>
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
>
http://groups.google.com/groups?q=s...ogle.com&rnum=2
anyone who might be[vbcol=seagreen]
>|||Hello John!
I was finally able to come up with a couple of solutions with the OPENQUERY,
and settled
on the Registry "dink" for the various "noise.*" extensions. (My other tech
nique was to
copy the specified noise file to a temporary file with a ".TXT" extension, b
ut that was
using [xp_cmdshell] and our users aren't members of the db_admin role an
d I was leery of
opening up the permissions on that procedure.)
Your option to populate a table with the noise words is intriguing, too. We
don't change
the noise list too often, but we *do* add stuff to it on occasion. I wonder
if I could
have a scheduled Job that would essentially keep the file in sync with the t
able every
week or so? Something like that might work better.
Our application will be caching the results of the OPENQUERY approach -- so
I don't feel
too bad about the potential "hit" for reading the file every time the SP is
invoked. But
it is more "clumsy" than just having a static table...
Thanks for the alternative suggestion -- I'll have to mull it over further!
:-)
"John Kane" <jt-kane@.comcast.net> wrote in message
news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> John,
> A most interesting solution! You would need to use ".ENU" in that list, th
en
> the above queries will work with "noise.enu" (US_English). Can I assume
> you've tried to import the noise word file into a table? For example:
> CREATE TABLE sqlfts_stop_words (
> term nvarchar(50) NOT NULL )
> GO
> ALTER TABLE sqlfts_stop_words ADD
> CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> GO
> -- Alter drive letter and path to noise.enu as appropriate
> BULK INSERT sqlfts_stop_words FROM
> 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Confi
g\noise.enu'
> GO
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> (*.txt; *.csv)};
> Shared\MSSearch\Data\Config\;', 'select
> openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program Files\Commo
n
> noise.txt')
> header row.
> try to change
> "allowable" extensions:
> work with
> "noise.eng" (the
> Transact-SQL.
> up with a
> Shared\MSSearch\Data\Config',
> were visible as
> something like:
> possible, and *not*
> "schema.ini" file,
> work:
> Files\Microsoft
> tried. :-(
> linked server.
> having to drop
>
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
>
http://groups.google.com/groups?q=s...ogle.com&rnum=2
> anyone who might be
>|||Hi John,
When you need to change the noise word file, you can setup a SQLServerAgent
job to BCP out to a noise.tmp text file, then stop the MSSearch service,
swap out the files and restart the MSSearch service and then run a Full
Population. You can make this as simple or as complex as you need. Also, for
the below BULK INSERT to work without errors, you will need to manually edit
the noise.enu file and place CR/LF after each single letter at the end of
the file, for example:
a b c d...
becomes
a
b
c
d...
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> Hello John!
> I was finally able to come up with a couple of solutions with the
OPENQUERY, and settled
> on the Registry "dink" for the various "noise.*" extensions. (My other
technique was to
> copy the specified noise file to a temporary file with a ".TXT" extension,
but that was
> using [xp_cmdshell] and our users aren't members of the db_admin role and[/vbc
ol]
I was leery of[vbcol=seagreen]
> opening up the permissions on that procedure.)
> Your option to populate a table with the noise words is intriguing, too.
We don't change
> the noise list too often, but we *do* add stuff to it on occasion. I
wonder if I could
> have a scheduled Job that would essentially keep the file in sync with the
table every
> week or so? Something like that might work better.
> Our application will be caching the results of the OPENQUERY approach --
so I don't feel
> too bad about the potential "hit" for reading the file every time the SP
is invoked. But
> it is more "clumsy" than just having a static table...
> Thanks for the alternative suggestion -- I'll have to mull it over
further! :-)
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
then[vbcol=seagreen]
Files\Common[vbcol=seagreen]
I[vbcol=seagreen]
will[vbcol=seagreen]
the[vbcol=seagreen]
come[vbcol=seagreen]
might[vbcol=seagreen]
Files\Common[vbcol=seagreen]
Properties="text;HDR=No;FMT=CSV";',[vbcol=seagreen]
I've[vbcol=seagreen]
a[vbcol=seagreen]
mind[vbcol=seagreen]
>
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
>
http://groups.google.com/groups?q=s...ogle.com&rnum=2
>|||Thanks John!
I notice that there's a line in the noise.enu file that is:
a b c d e ... x y z
I'm assuming that "word" is really a space-delimited list of single noise wo
rds? If I
leave that "as is", will that be a problem? Or is there something with the
mechanics of
the BULK INSERT that will give me problems with that? I can easily "parse"
those values
out into the "expanded list", so I don't mind leaving it the way it is, unle
ss it hoses up
the BULK INSERT.
Can I also assume, then, that I could potentially put other multiple noise w
ords on the
same line, separated by a space if I wanted to? What if I wanted a *phrase*
to be ignored
that contained spaces?
Thanks again for your help!
John Peterson
"John Kane" <jt-kane@.comcast.net> wrote in message
news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
> Hi John,
> When you need to change the noise word file, you can setup a SQLServerAgen
t
> job to BCP out to a noise.tmp text file, then stop the MSSearch service,
> swap out the files and restart the MSSearch service and then run a Full
> Population. You can make this as simple or as complex as you need. Also, f
or
> the below BULK INSERT to work without errors, you will need to manually ed
it
> the noise.enu file and place CR/LF after each single letter at the end of
> the file, for example:
> a b c d...
> becomes
> a
> b
> c
> d...
> Regards,
> John
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> OPENQUERY, and settled
> technique was to
> but that was
> I was leery of
> We don't change
> wonder if I could
> table every
> so I don't feel
> is invoked. But
> further! :-)
> then
> Files\Common
> I
> will
> the
> come
> might
> Files\Common
> Properties="text;HDR=No;FMT=CSV";',
> I've
> a
> mind
>
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
>
http://groups.google.com/groups?q=s...ogle.com&rnum=2
>|||Yes, that's the line I'm referring to... Yes, if you leave it "as is" it
will cause the BULK INSERT to throw an error and the single letters will not
be imported. However, making the change does not affect MSSearch, it's just
that the bulk insert hick-ups with the spaces between the single letters.
No, your assumption is incorrect (I've already tried that years ago ;-) and
the multiple-word noise phrases are ignored by MSSearch.
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#f1$$R#MEHA.3972@.TK2MSFTNGP10.phx.gbl...
> Thanks John!
> I notice that there's a line in the noise.enu file that is:
> a b c d e ... x y z
> I'm assuming that "word" is really a space-delimited list of single noise
words? If I
> leave that "as is", will that be a problem? Or is there something with
the mechanics of
> the BULK INSERT that will give me problems with that? I can easily
"parse" those values
> out into the "expanded list", so I don't mind leaving it the way it is,
unless it hoses up
> the BULK INSERT.
> Can I also assume, then, that I could potentially put other multiple noise
words on the
> same line, separated by a space if I wanted to? What if I wanted a
*phrase* to be ignored
> that contained spaces?
> Thanks again for your help!
> John Peterson
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
SQLServerAgent[vbcol=seagreen]
for[vbcol=seagreen]
edit[vbcol=seagreen]
of[vbcol=seagreen]
other[vbcol=seagreen]
extension,[vbcol=seagreen]
and[vbcol=seagreen]
too.[vbcol=seagreen]
the[vbcol=seagreen]
approach --[vbcol=seagreen]
SP[vbcol=seagreen]
list,[vbcol=seagreen]
assume[vbcol=seagreen]
example:[vbcol=seagreen]
Driver[vbcol=seagreen]
from[vbcol=seagreen]
is no[vbcol=seagreen]
If[vbcol=seagreen]
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Je
t\4. 0\Engines\Text\Extensions[vbcol=seagreen
]
queries[vbcol=seagreen]
though.[vbcol=seagreen]
reference[vbcol=seagreen]
through[vbcol=seagreen]
Shared\MSSearch\Data\Config[vbcol=seagre
en]
Server\MSSQL\FTDATA\SQLServer\Config[vbc
ol=seagreen]
to[vbcol=seagreen]
extension[vbcol=seagreen]
available.[vbcol=seagreen]
as a[vbcol=seagreen]
all[vbcol=seagreen]
use a[vbcol=seagreen]
thought[vbcol=seagreen]
variants[vbcol=seagreen]
create[vbcol=seagreen]
don't[vbcol=seagreen]
directory.[vbcol=seagreen]
information:[vbcol=seagreen]
>
http://groups.google.com/groups?q=s...SFTNGP10&rnum=6
>
http://groups.google.com/groups?q=s...ogle.com&rnum=2
to[vbcol=seagreen]
>

Question about referencing Full-Text noise file through SQL rowset functions.

(SQL Server 2000, SP3a)
Hello all!
I'm trying to cobble together something that will let me reference the "noise.eng" (the
English list of the Full Text Search service ignored words) through Transact-SQL.
I'm trying to reference the "noise.eng" file that's located in:
C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
There are a couple others in:
C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
C:\windows\SYSTEM32
but the one in the "Common Files" had the most recent date. :-)
I *have* had some measure of success with it -- but I'm trying to come up with a "cleaner"
way, if possible.
This is how I got this to work:
First I tried setting up a linked server:
--Create a linked server
execute [dbo].[sp_addlinkedserver]
'TextTest',
'Jet 4.0',
'Microsoft.Jet.OLEDB.4.0',
'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
NULL,
'Text'
go
--Set up login mappings
execute [dbo].[sp_addlinkedsrvlogin]
'TextTest',
FALSE,
NULL,
NULL
go
Then I checked out the tables that were available:
--List the tables in the linked server
execute [dbo].[sp_tables_ex] 'TextTest'
go
Interestingly, all the files in that directory with a .TXT extension were visible as
tables! However, the "noise.eng" file didn't seem to be available.
If I copied the "noise.eng" file to "noise.txt", then I could do something like:
select * from TextTest...[noise#txt]
or
select * from openquery(TextTest, 'select * from [noise#txt]') as a
And that seems to return the information! :-)
You can clean up the linked servers with:
execute [dbo].[sp_droplinkedsrvlogin]
'TextTest', NULL
go
execute [dbo].[sp_dropserver]
'TextTest'
go
However, I'd really like to use the OPENROWSET function if at all possible, and *not* have
to rename/copy the noise.eng file. I was reading that I could use a "schema.ini" file,
and after browsing the web, discovered this format that I thought might work:
[noise.eng]
ColNameHeader = False
CharacterSet = ANSI
Format = CSVDelimited
Col1=NoiseWord Char Width 100
Then I tried doing something like:
select *
from openrowset
(
'Microsoft.Jet.OLEDB.4.0',
'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
'select * from noise.eng'
) as a
Which doesn't quite work -- nor have any of the OPENROWSET variants I've tried. :-(
I'd like to be able to use OPENROWSET so that I don't have to create a linked server. I'd
also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to drop in
a "schema.ini" (if that's even necessary/helpful) in that directory.
I've found the following URLs to be useful sources of information:
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
Sorry for the length of this post, but I sure would be grateful to anyone who might be
able to help! :-)
John PetersonI think I've been able to get close with some of this:
select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver (*.txt; *.csv)};
DefaultDir=C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config\;', 'select
* from noise.txt')
However, this seems to treat the first row as a header row.
select * from openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program Files\Common
Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from noise.txt')
This is the closest I found, and allows me to specify that there is no header row.
The only remaining nit is that I *must* have an extension of .TXT. If I try to change
"noise.txt" to "noise.eng", I get errors.
A colleague of mine discovered that the JET driver has a list of "allowable" extensions:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Extensions
My guess is that if I put ".ENG" in that list, then the above queries will work with
"noise.eng". I was hoping to avoid modifying the Registry, though.
Does anyone know of a way to circumvent this issue?
Thanks!
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello all!
> I'm trying to cobble together something that will let me reference the "noise.eng" (the
> English list of the Full Text Search service ignored words) through Transact-SQL.
> I'm trying to reference the "noise.eng" file that's located in:
> C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> There are a couple others in:
> C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> C:\windows\SYSTEM32
> but the one in the "Common Files" had the most recent date. :-)
> I *have* had some measure of success with it -- but I'm trying to come up with a
"cleaner"
> way, if possible.
> This is how I got this to work:
> First I tried setting up a linked server:
> --Create a linked server
> execute [dbo].[sp_addlinkedserver]
> 'TextTest',
> 'Jet 4.0',
> 'Microsoft.Jet.OLEDB.4.0',
> 'C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config',
> NULL,
> 'Text'
> go
> --Set up login mappings
> execute [dbo].[sp_addlinkedsrvlogin]
> 'TextTest',
> FALSE,
> NULL,
> NULL
> go
> Then I checked out the tables that were available:
> --List the tables in the linked server
> execute [dbo].[sp_tables_ex] 'TextTest'
> go
> Interestingly, all the files in that directory with a .TXT extension were visible as
> tables! However, the "noise.eng" file didn't seem to be available.
> If I copied the "noise.eng" file to "noise.txt", then I could do something like:
> select * from TextTest...[noise#txt]
> or
> select * from openquery(TextTest, 'select * from [noise#txt]') as a
> And that seems to return the information! :-)
> You can clean up the linked servers with:
> execute [dbo].[sp_droplinkedsrvlogin]
> 'TextTest', NULL
> go
> execute [dbo].[sp_dropserver]
> 'TextTest'
> go
> However, I'd really like to use the OPENROWSET function if at all possible, and *not*
have
> to rename/copy the noise.eng file. I was reading that I could use a "schema.ini" file,
> and after browsing the web, discovered this format that I thought might work:
> [noise.eng]
> ColNameHeader = False
> CharacterSet = ANSI
> Format = CSVDelimited
> Col1=NoiseWord Char Width 100
> Then I tried doing something like:
> select *
> from openrowset
> (
> 'Microsoft.Jet.OLEDB.4.0',
> 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common Files\Microsoft
> Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
> 'select * from noise.eng'
> ) as a
> Which doesn't quite work -- nor have any of the OPENROWSET variants I've tried. :-(
> I'd like to be able to use OPENROWSET so that I don't have to create a linked server.
I'd
> also like to avoid copying the "noise.eng" to "noise.txt". I don't mind having to drop
in
> a "schema.ini" (if that's even necessary/helpful) in that directory.
> I've found the following URLs to be useful sources of information:
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
> Sorry for the length of this post, but I sure would be grateful to anyone who might be
> able to help! :-)
> John Peterson
>|||John,
A most interesting solution! You would need to use ".ENU" in that list, then
the above queries will work with "noise.enu" (US_English). Can I assume
you've tried to import the noise word file into a table? For example:
CREATE TABLE sqlfts_stop_words (
term nvarchar(50) NOT NULL )
GO
ALTER TABLE sqlfts_stop_words ADD
CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
GO
-- Alter drive letter and path to noise.enu as appropriate
BULK INSERT sqlfts_stop_words FROM
'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.enu'
GO
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> I think I've been able to get close with some of this:
> select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
(*.txt; *.csv)};
> DefaultDir=C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config\;', 'select
> * from noise.txt')
> However, this seems to treat the first row as a header row.
> select * from
openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program Files\Common
> Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
noise.txt')
> This is the closest I found, and allows me to specify that there is no
header row.
> The only remaining nit is that I *must* have an extension of .TXT. If I
try to change
> "noise.txt" to "noise.eng", I get errors.
> A colleague of mine discovered that the JET driver has a list of
"allowable" extensions:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Extensions
> My guess is that if I put ".ENG" in that list, then the above queries will
work with
> "noise.eng". I was hoping to avoid modifying the Registry, though.
> Does anyone know of a way to circumvent this issue?
> Thanks!
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> > (SQL Server 2000, SP3a)
> >
> > Hello all!
> >
> > I'm trying to cobble together something that will let me reference the
"noise.eng" (the
> > English list of the Full Text Search service ignored words) through
Transact-SQL.
> >
> > I'm trying to reference the "noise.eng" file that's located in:
> >
> > C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> >
> > There are a couple others in:
> >
> > C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> > C:\windows\SYSTEM32
> >
> > but the one in the "Common Files" had the most recent date. :-)
> >
> > I *have* had some measure of success with it -- but I'm trying to come
up with a
> "cleaner"
> > way, if possible.
> >
> > This is how I got this to work:
> >
> > First I tried setting up a linked server:
> >
> > --Create a linked server
> > execute [dbo].[sp_addlinkedserver]
> > 'TextTest',
> > 'Jet 4.0',
> > 'Microsoft.Jet.OLEDB.4.0',
> > 'C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config',
> > NULL,
> > 'Text'
> > go
> >
> > --Set up login mappings
> > execute [dbo].[sp_addlinkedsrvlogin]
> > 'TextTest',
> > FALSE,
> > NULL,
> > NULL
> > go
> >
> > Then I checked out the tables that were available:
> >
> > --List the tables in the linked server
> > execute [dbo].[sp_tables_ex] 'TextTest'
> > go
> >
> > Interestingly, all the files in that directory with a .TXT extension
were visible as
> > tables! However, the "noise.eng" file didn't seem to be available.
> >
> > If I copied the "noise.eng" file to "noise.txt", then I could do
something like:
> >
> > select * from TextTest...[noise#txt]
> >
> > or
> >
> > select * from openquery(TextTest, 'select * from [noise#txt]') as a
> >
> > And that seems to return the information! :-)
> >
> > You can clean up the linked servers with:
> >
> > execute [dbo].[sp_droplinkedsrvlogin]
> > 'TextTest', NULL
> > go
> >
> > execute [dbo].[sp_dropserver]
> > 'TextTest'
> > go
> >
> > However, I'd really like to use the OPENROWSET function if at all
possible, and *not*
> have
> > to rename/copy the noise.eng file. I was reading that I could use a
"schema.ini" file,
> > and after browsing the web, discovered this format that I thought might
work:
> >
> > [noise.eng]
> > ColNameHeader = False
> > CharacterSet = ANSI
> > Format = CSVDelimited
> > Col1=NoiseWord Char Width 100
> >
> > Then I tried doing something like:
> >
> > select *
> > from openrowset
> > (
> > 'Microsoft.Jet.OLEDB.4.0',
> > 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common
Files\Microsoft
> > Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
> > 'select * from noise.eng'
> > ) as a
> >
> > Which doesn't quite work -- nor have any of the OPENROWSET variants I've
tried. :-(
> >
> > I'd like to be able to use OPENROWSET so that I don't have to create a
linked server.
> I'd
> > also like to avoid copying the "noise.eng" to "noise.txt". I don't mind
having to drop
> in
> > a "schema.ini" (if that's even necessary/helpful) in that directory.
> >
> > I've found the following URLs to be useful sources of information:
> >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
> >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
> >
> > Sorry for the length of this post, but I sure would be grateful to
anyone who might be
> > able to help! :-)
> >
> > John Peterson
> >
> >
>|||Hello John!
I was finally able to come up with a couple of solutions with the OPENQUERY, and settled
on the Registry "dink" for the various "noise.*" extensions. (My other technique was to
copy the specified noise file to a temporary file with a ".TXT" extension, but that was
using [xp_cmdshell] and our users aren't members of the db_admin role and I was leery of
opening up the permissions on that procedure.)
Your option to populate a table with the noise words is intriguing, too. We don't change
the noise list too often, but we *do* add stuff to it on occasion. I wonder if I could
have a scheduled Job that would essentially keep the file in sync with the table every
week or so? Something like that might work better.
Our application will be caching the results of the OPENQUERY approach -- so I don't feel
too bad about the potential "hit" for reading the file every time the SP is invoked. But
it is more "clumsy" than just having a static table...
Thanks for the alternative suggestion -- I'll have to mull it over further! :-)
"John Kane" <jt-kane@.comcast.net> wrote in message
news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> John,
> A most interesting solution! You would need to use ".ENU" in that list, then
> the above queries will work with "noise.enu" (US_English). Can I assume
> you've tried to import the noise word file into a table? For example:
> CREATE TABLE sqlfts_stop_words (
> term nvarchar(50) NOT NULL )
> GO
> ALTER TABLE sqlfts_stop_words ADD
> CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> GO
> -- Alter drive letter and path to noise.enu as appropriate
> BULK INSERT sqlfts_stop_words FROM
> 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.enu'
> GO
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> > I think I've been able to get close with some of this:
> >
> > select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
> (*.txt; *.csv)};
> > DefaultDir=C:\Program Files\Common Files\Microsoft
> Shared\MSSearch\Data\Config\;', 'select
> > * from noise.txt')
> >
> > However, this seems to treat the first row as a header row.
> >
> > select * from
> openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program Files\Common
> > Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
> noise.txt')
> >
> > This is the closest I found, and allows me to specify that there is no
> header row.
> >
> > The only remaining nit is that I *must* have an extension of .TXT. If I
> try to change
> > "noise.txt" to "noise.eng", I get errors.
> >
> > A colleague of mine discovered that the JET driver has a list of
> "allowable" extensions:
> >
> > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Extensions
> >
> > My guess is that if I put ".ENG" in that list, then the above queries will
> work with
> > "noise.eng". I was hoping to avoid modifying the Registry, though.
> >
> > Does anyone know of a way to circumvent this issue?
> >
> > Thanks!
> >
> > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> > > (SQL Server 2000, SP3a)
> > >
> > > Hello all!
> > >
> > > I'm trying to cobble together something that will let me reference the
> "noise.eng" (the
> > > English list of the Full Text Search service ignored words) through
> Transact-SQL.
> > >
> > > I'm trying to reference the "noise.eng" file that's located in:
> > >
> > > C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> > >
> > > There are a couple others in:
> > >
> > > C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> > > C:\windows\SYSTEM32
> > >
> > > but the one in the "Common Files" had the most recent date. :-)
> > >
> > > I *have* had some measure of success with it -- but I'm trying to come
> up with a
> > "cleaner"
> > > way, if possible.
> > >
> > > This is how I got this to work:
> > >
> > > First I tried setting up a linked server:
> > >
> > > --Create a linked server
> > > execute [dbo].[sp_addlinkedserver]
> > > 'TextTest',
> > > 'Jet 4.0',
> > > 'Microsoft.Jet.OLEDB.4.0',
> > > 'C:\Program Files\Common Files\Microsoft
> Shared\MSSearch\Data\Config',
> > > NULL,
> > > 'Text'
> > > go
> > >
> > > --Set up login mappings
> > > execute [dbo].[sp_addlinkedsrvlogin]
> > > 'TextTest',
> > > FALSE,
> > > NULL,
> > > NULL
> > > go
> > >
> > > Then I checked out the tables that were available:
> > >
> > > --List the tables in the linked server
> > > execute [dbo].[sp_tables_ex] 'TextTest'
> > > go
> > >
> > > Interestingly, all the files in that directory with a .TXT extension
> were visible as
> > > tables! However, the "noise.eng" file didn't seem to be available.
> > >
> > > If I copied the "noise.eng" file to "noise.txt", then I could do
> something like:
> > >
> > > select * from TextTest...[noise#txt]
> > >
> > > or
> > >
> > > select * from openquery(TextTest, 'select * from [noise#txt]') as a
> > >
> > > And that seems to return the information! :-)
> > >
> > > You can clean up the linked servers with:
> > >
> > > execute [dbo].[sp_droplinkedsrvlogin]
> > > 'TextTest', NULL
> > > go
> > >
> > > execute [dbo].[sp_dropserver]
> > > 'TextTest'
> > > go
> > >
> > > However, I'd really like to use the OPENROWSET function if at all
> possible, and *not*
> > have
> > > to rename/copy the noise.eng file. I was reading that I could use a
> "schema.ini" file,
> > > and after browsing the web, discovered this format that I thought might
> work:
> > >
> > > [noise.eng]
> > > ColNameHeader = False
> > > CharacterSet = ANSI
> > > Format = CSVDelimited
> > > Col1=NoiseWord Char Width 100
> > >
> > > Then I tried doing something like:
> > >
> > > select *
> > > from openrowset
> > > (
> > > 'Microsoft.Jet.OLEDB.4.0',
> > > 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program Files\Common
> Files\Microsoft
> > > Shared\MSSearch\Data\Config;Extended Properties="text;HDR=No;FMT=CSV";',
> > > 'select * from noise.eng'
> > > ) as a
> > >
> > > Which doesn't quite work -- nor have any of the OPENROWSET variants I've
> tried. :-(
> > >
> > > I'd like to be able to use OPENROWSET so that I don't have to create a
> linked server.
> > I'd
> > > also like to avoid copying the "noise.eng" to "noise.txt". I don't mind
> having to drop
> > in
> > > a "schema.ini" (if that's even necessary/helpful) in that directory.
> > >
> > > I've found the following URLs to be useful sources of information:
> > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
> > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
> > >
> > > Sorry for the length of this post, but I sure would be grateful to
> anyone who might be
> > > able to help! :-)
> > >
> > > John Peterson
> > >
> > >
> >
> >
>|||Hi John,
When you need to change the noise word file, you can setup a SQLServerAgent
job to BCP out to a noise.tmp text file, then stop the MSSearch service,
swap out the files and restart the MSSearch service and then run a Full
Population. You can make this as simple or as complex as you need. Also, for
the below BULK INSERT to work without errors, you will need to manually edit
the noise.enu file and place CR/LF after each single letter at the end of
the file, for example:
a b c d...
becomes
a
b
c
d...
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> Hello John!
> I was finally able to come up with a couple of solutions with the
OPENQUERY, and settled
> on the Registry "dink" for the various "noise.*" extensions. (My other
technique was to
> copy the specified noise file to a temporary file with a ".TXT" extension,
but that was
> using [xp_cmdshell] and our users aren't members of the db_admin role and
I was leery of
> opening up the permissions on that procedure.)
> Your option to populate a table with the noise words is intriguing, too.
We don't change
> the noise list too often, but we *do* add stuff to it on occasion. I
wonder if I could
> have a scheduled Job that would essentially keep the file in sync with the
table every
> week or so? Something like that might work better.
> Our application will be caching the results of the OPENQUERY approach --
so I don't feel
> too bad about the potential "hit" for reading the file every time the SP
is invoked. But
> it is more "clumsy" than just having a static table...
> Thanks for the alternative suggestion -- I'll have to mull it over
further! :-)
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> > John,
> > A most interesting solution! You would need to use ".ENU" in that list,
then
> > the above queries will work with "noise.enu" (US_English). Can I assume
> > you've tried to import the noise word file into a table? For example:
> >
> > CREATE TABLE sqlfts_stop_words (
> > term nvarchar(50) NOT NULL )
> > GO
> > ALTER TABLE sqlfts_stop_words ADD
> > CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> > GO
> > -- Alter drive letter and path to noise.enu as appropriate
> > BULK INSERT sqlfts_stop_words FROM
> > 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.enu'
> > GO
> >
> >
> >
> > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> > > I think I've been able to get close with some of this:
> > >
> > > select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
> > (*.txt; *.csv)};
> > > DefaultDir=C:\Program Files\Common Files\Microsoft
> > Shared\MSSearch\Data\Config\;', 'select
> > > * from noise.txt')
> > >
> > > However, this seems to treat the first row as a header row.
> > >
> > > select * from
> > openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program
Files\Common
> > > Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
> > noise.txt')
> > >
> > > This is the closest I found, and allows me to specify that there is no
> > header row.
> > >
> > > The only remaining nit is that I *must* have an extension of .TXT. If
I
> > try to change
> > > "noise.txt" to "noise.eng", I get errors.
> > >
> > > A colleague of mine discovered that the JET driver has a list of
> > "allowable" extensions:
> > >
> > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Extensions
> > >
> > > My guess is that if I put ".ENG" in that list, then the above queries
will
> > work with
> > > "noise.eng". I was hoping to avoid modifying the Registry, though.
> > >
> > > Does anyone know of a way to circumvent this issue?
> > >
> > > Thanks!
> > >
> > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> > > > (SQL Server 2000, SP3a)
> > > >
> > > > Hello all!
> > > >
> > > > I'm trying to cobble together something that will let me reference
the
> > "noise.eng" (the
> > > > English list of the Full Text Search service ignored words) through
> > Transact-SQL.
> > > >
> > > > I'm trying to reference the "noise.eng" file that's located in:
> > > >
> > > > C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> > > >
> > > > There are a couple others in:
> > > >
> > > > C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> > > > C:\windows\SYSTEM32
> > > >
> > > > but the one in the "Common Files" had the most recent date. :-)
> > > >
> > > > I *have* had some measure of success with it -- but I'm trying to
come
> > up with a
> > > "cleaner"
> > > > way, if possible.
> > > >
> > > > This is how I got this to work:
> > > >
> > > > First I tried setting up a linked server:
> > > >
> > > > --Create a linked server
> > > > execute [dbo].[sp_addlinkedserver]
> > > > 'TextTest',
> > > > 'Jet 4.0',
> > > > 'Microsoft.Jet.OLEDB.4.0',
> > > > 'C:\Program Files\Common Files\Microsoft
> > Shared\MSSearch\Data\Config',
> > > > NULL,
> > > > 'Text'
> > > > go
> > > >
> > > > --Set up login mappings
> > > > execute [dbo].[sp_addlinkedsrvlogin]
> > > > 'TextTest',
> > > > FALSE,
> > > > NULL,
> > > > NULL
> > > > go
> > > >
> > > > Then I checked out the tables that were available:
> > > >
> > > > --List the tables in the linked server
> > > > execute [dbo].[sp_tables_ex] 'TextTest'
> > > > go
> > > >
> > > > Interestingly, all the files in that directory with a .TXT extension
> > were visible as
> > > > tables! However, the "noise.eng" file didn't seem to be available.
> > > >
> > > > If I copied the "noise.eng" file to "noise.txt", then I could do
> > something like:
> > > >
> > > > select * from TextTest...[noise#txt]
> > > >
> > > > or
> > > >
> > > > select * from openquery(TextTest, 'select * from [noise#txt]') as a
> > > >
> > > > And that seems to return the information! :-)
> > > >
> > > > You can clean up the linked servers with:
> > > >
> > > > execute [dbo].[sp_droplinkedsrvlogin]
> > > > 'TextTest', NULL
> > > > go
> > > >
> > > > execute [dbo].[sp_dropserver]
> > > > 'TextTest'
> > > > go
> > > >
> > > > However, I'd really like to use the OPENROWSET function if at all
> > possible, and *not*
> > > have
> > > > to rename/copy the noise.eng file. I was reading that I could use a
> > "schema.ini" file,
> > > > and after browsing the web, discovered this format that I thought
might
> > work:
> > > >
> > > > [noise.eng]
> > > > ColNameHeader = False
> > > > CharacterSet = ANSI
> > > > Format = CSVDelimited
> > > > Col1=NoiseWord Char Width 100
> > > >
> > > > Then I tried doing something like:
> > > >
> > > > select *
> > > > from openrowset
> > > > (
> > > > 'Microsoft.Jet.OLEDB.4.0',
> > > > 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program
Files\Common
> > Files\Microsoft
> > > > Shared\MSSearch\Data\Config;Extended
Properties="text;HDR=No;FMT=CSV";',
> > > > 'select * from noise.eng'
> > > > ) as a
> > > >
> > > > Which doesn't quite work -- nor have any of the OPENROWSET variants
I've
> > tried. :-(
> > > >
> > > > I'd like to be able to use OPENROWSET so that I don't have to create
a
> > linked server.
> > > I'd
> > > > also like to avoid copying the "noise.eng" to "noise.txt". I don't
mind
> > having to drop
> > > in
> > > > a "schema.ini" (if that's even necessary/helpful) in that directory.
> > > >
> > > > I've found the following URLs to be useful sources of information:
> > > >
> > > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
> > > >
> > > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
> > > >
> > > > Sorry for the length of this post, but I sure would be grateful to
> > anyone who might be
> > > > able to help! :-)
> > > >
> > > > John Peterson
> > > >
> > > >
> > >
> > >
> >
> >
>|||Thanks John!
I notice that there's a line in the noise.enu file that is:
a b c d e ... x y z
I'm assuming that "word" is really a space-delimited list of single noise words? If I
leave that "as is", will that be a problem? Or is there something with the mechanics of
the BULK INSERT that will give me problems with that? I can easily "parse" those values
out into the "expanded list", so I don't mind leaving it the way it is, unless it hoses up
the BULK INSERT.
Can I also assume, then, that I could potentially put other multiple noise words on the
same line, separated by a space if I wanted to? What if I wanted a *phrase* to be ignored
that contained spaces?
Thanks again for your help!
John Peterson
"John Kane" <jt-kane@.comcast.net> wrote in message
news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
> Hi John,
> When you need to change the noise word file, you can setup a SQLServerAgent
> job to BCP out to a noise.tmp text file, then stop the MSSearch service,
> swap out the files and restart the MSSearch service and then run a Full
> Population. You can make this as simple or as complex as you need. Also, for
> the below BULK INSERT to work without errors, you will need to manually edit
> the noise.enu file and place CR/LF after each single letter at the end of
> the file, for example:
> a b c d...
> becomes
> a
> b
> c
> d...
> Regards,
> John
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> > Hello John!
> >
> > I was finally able to come up with a couple of solutions with the
> OPENQUERY, and settled
> > on the Registry "dink" for the various "noise.*" extensions. (My other
> technique was to
> > copy the specified noise file to a temporary file with a ".TXT" extension,
> but that was
> > using [xp_cmdshell] and our users aren't members of the db_admin role and
> I was leery of
> > opening up the permissions on that procedure.)
> >
> > Your option to populate a table with the noise words is intriguing, too.
> We don't change
> > the noise list too often, but we *do* add stuff to it on occasion. I
> wonder if I could
> > have a scheduled Job that would essentially keep the file in sync with the
> table every
> > week or so? Something like that might work better.
> >
> > Our application will be caching the results of the OPENQUERY approach --
> so I don't feel
> > too bad about the potential "hit" for reading the file every time the SP
> is invoked. But
> > it is more "clumsy" than just having a static table...
> >
> > Thanks for the alternative suggestion -- I'll have to mull it over
> further! :-)
> >
> >
> > "John Kane" <jt-kane@.comcast.net> wrote in message
> > news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> > > John,
> > > A most interesting solution! You would need to use ".ENU" in that list,
> then
> > > the above queries will work with "noise.enu" (US_English). Can I assume
> > > you've tried to import the noise word file into a table? For example:
> > >
> > > CREATE TABLE sqlfts_stop_words (
> > > term nvarchar(50) NOT NULL )
> > > GO
> > > ALTER TABLE sqlfts_stop_words ADD
> > > CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> > > GO
> > > -- Alter drive letter and path to noise.enu as appropriate
> > > BULK INSERT sqlfts_stop_words FROM
> > > 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.enu'
> > > GO
> > >
> > >
> > >
> > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> > > > I think I've been able to get close with some of this:
> > > >
> > > > select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text Driver
> > > (*.txt; *.csv)};
> > > > DefaultDir=C:\Program Files\Common Files\Microsoft
> > > Shared\MSSearch\Data\Config\;', 'select
> > > > * from noise.txt')
> > > >
> > > > However, this seems to treat the first row as a header row.
> > > >
> > > > select * from
> > > openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program
> Files\Common
> > > > Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select * from
> > > noise.txt')
> > > >
> > > > This is the closest I found, and allows me to specify that there is no
> > > header row.
> > > >
> > > > The only remaining nit is that I *must* have an extension of .TXT. If
> I
> > > try to change
> > > > "noise.txt" to "noise.eng", I get errors.
> > > >
> > > > A colleague of mine discovered that the JET driver has a list of
> > > "allowable" extensions:
> > > >
> > > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Extensions
> > > >
> > > > My guess is that if I put ".ENG" in that list, then the above queries
> will
> > > work with
> > > > "noise.eng". I was hoping to avoid modifying the Registry, though.
> > > >
> > > > Does anyone know of a way to circumvent this issue?
> > > >
> > > > Thanks!
> > > >
> > > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > > news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> > > > > (SQL Server 2000, SP3a)
> > > > >
> > > > > Hello all!
> > > > >
> > > > > I'm trying to cobble together something that will let me reference
> the
> > > "noise.eng" (the
> > > > > English list of the Full Text Search service ignored words) through
> > > Transact-SQL.
> > > > >
> > > > > I'm trying to reference the "noise.eng" file that's located in:
> > > > >
> > > > > C:\Program Files\Common Files\Microsoft Shared\MSSearch\Data\Config
> > > > >
> > > > > There are a couple others in:
> > > > >
> > > > > C:\Program Files\Microsoft SQL Server\MSSQL\FTDATA\SQLServer\Config
> > > > > C:\windows\SYSTEM32
> > > > >
> > > > > but the one in the "Common Files" had the most recent date. :-)
> > > > >
> > > > > I *have* had some measure of success with it -- but I'm trying to
> come
> > > up with a
> > > > "cleaner"
> > > > > way, if possible.
> > > > >
> > > > > This is how I got this to work:
> > > > >
> > > > > First I tried setting up a linked server:
> > > > >
> > > > > --Create a linked server
> > > > > execute [dbo].[sp_addlinkedserver]
> > > > > 'TextTest',
> > > > > 'Jet 4.0',
> > > > > 'Microsoft.Jet.OLEDB.4.0',
> > > > > 'C:\Program Files\Common Files\Microsoft
> > > Shared\MSSearch\Data\Config',
> > > > > NULL,
> > > > > 'Text'
> > > > > go
> > > > >
> > > > > --Set up login mappings
> > > > > execute [dbo].[sp_addlinkedsrvlogin]
> > > > > 'TextTest',
> > > > > FALSE,
> > > > > NULL,
> > > > > NULL
> > > > > go
> > > > >
> > > > > Then I checked out the tables that were available:
> > > > >
> > > > > --List the tables in the linked server
> > > > > execute [dbo].[sp_tables_ex] 'TextTest'
> > > > > go
> > > > >
> > > > > Interestingly, all the files in that directory with a .TXT extension
> > > were visible as
> > > > > tables! However, the "noise.eng" file didn't seem to be available.
> > > > >
> > > > > If I copied the "noise.eng" file to "noise.txt", then I could do
> > > something like:
> > > > >
> > > > > select * from TextTest...[noise#txt]
> > > > >
> > > > > or
> > > > >
> > > > > select * from openquery(TextTest, 'select * from [noise#txt]') as a
> > > > >
> > > > > And that seems to return the information! :-)
> > > > >
> > > > > You can clean up the linked servers with:
> > > > >
> > > > > execute [dbo].[sp_droplinkedsrvlogin]
> > > > > 'TextTest', NULL
> > > > > go
> > > > >
> > > > > execute [dbo].[sp_dropserver]
> > > > > 'TextTest'
> > > > > go
> > > > >
> > > > > However, I'd really like to use the OPENROWSET function if at all
> > > possible, and *not*
> > > > have
> > > > > to rename/copy the noise.eng file. I was reading that I could use a
> > > "schema.ini" file,
> > > > > and after browsing the web, discovered this format that I thought
> might
> > > work:
> > > > >
> > > > > [noise.eng]
> > > > > ColNameHeader = False
> > > > > CharacterSet = ANSI
> > > > > Format = CSVDelimited
> > > > > Col1=NoiseWord Char Width 100
> > > > >
> > > > > Then I tried doing something like:
> > > > >
> > > > > select *
> > > > > from openrowset
> > > > > (
> > > > > 'Microsoft.Jet.OLEDB.4.0',
> > > > > 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program
> Files\Common
> > > Files\Microsoft
> > > > > Shared\MSSearch\Data\Config;Extended
> Properties="text;HDR=No;FMT=CSV";',
> > > > > 'select * from noise.eng'
> > > > > ) as a
> > > > >
> > > > > Which doesn't quite work -- nor have any of the OPENROWSET variants
> I've
> > > tried. :-(
> > > > >
> > > > > I'd like to be able to use OPENROWSET so that I don't have to create
> a
> > > linked server.
> > > > I'd
> > > > > also like to avoid copying the "noise.eng" to "noise.txt". I don't
> mind
> > > having to drop
> > > > in
> > > > > a "schema.ini" (if that's even necessary/helpful) in that directory.
> > > > >
> > > > > I've found the following URLs to be useful sources of information:
> > > > >
> > > > >
> > > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
> > > > >
> > > > >
> > > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
> > > > >
> > > > > Sorry for the length of this post, but I sure would be grateful to
> > > anyone who might be
> > > > > able to help! :-)
> > > > >
> > > > > John Peterson
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>|||Yes, that's the line I'm referring to... Yes, if you leave it "as is" it
will cause the BULK INSERT to throw an error and the single letters will not
be imported. However, making the change does not affect MSSearch, it's just
that the bulk insert hick-ups with the spaces between the single letters.
No, your assumption is incorrect (I've already tried that years ago ;-) and
the multiple-word noise phrases are ignored by MSSearch.
Regards,
John
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:#f1$$R#MEHA.3972@.TK2MSFTNGP10.phx.gbl...
> Thanks John!
> I notice that there's a line in the noise.enu file that is:
> a b c d e ... x y z
> I'm assuming that "word" is really a space-delimited list of single noise
words? If I
> leave that "as is", will that be a problem? Or is there something with
the mechanics of
> the BULK INSERT that will give me problems with that? I can easily
"parse" those values
> out into the "expanded list", so I don't mind leaving it the way it is,
unless it hoses up
> the BULK INSERT.
> Can I also assume, then, that I could potentially put other multiple noise
words on the
> same line, separated by a space if I wanted to? What if I wanted a
*phrase* to be ignored
> that contained spaces?
> Thanks again for your help!
> John Peterson
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:u9t$H88MEHA.3556@.TK2MSFTNGP09.phx.gbl...
> > Hi John,
> > When you need to change the noise word file, you can setup a
SQLServerAgent
> > job to BCP out to a noise.tmp text file, then stop the MSSearch service,
> > swap out the files and restart the MSSearch service and then run a Full
> > Population. You can make this as simple or as complex as you need. Also,
for
> > the below BULK INSERT to work without errors, you will need to manually
edit
> > the noise.enu file and place CR/LF after each single letter at the end
of
> > the file, for example:
> >
> > a b c d...
> > becomes
> > a
> > b
> > c
> > d...
> >
> > Regards,
> > John
> >
> >
> > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > news:uXsOZ2yMEHA.2976@.TK2MSFTNGP10.phx.gbl...
> > > Hello John!
> > >
> > > I was finally able to come up with a couple of solutions with the
> > OPENQUERY, and settled
> > > on the Registry "dink" for the various "noise.*" extensions. (My
other
> > technique was to
> > > copy the specified noise file to a temporary file with a ".TXT"
extension,
> > but that was
> > > using [xp_cmdshell] and our users aren't members of the db_admin role
and
> > I was leery of
> > > opening up the permissions on that procedure.)
> > >
> > > Your option to populate a table with the noise words is intriguing,
too.
> > We don't change
> > > the noise list too often, but we *do* add stuff to it on occasion. I
> > wonder if I could
> > > have a scheduled Job that would essentially keep the file in sync with
the
> > table every
> > > week or so? Something like that might work better.
> > >
> > > Our application will be caching the results of the OPENQUERY
approach --
> > so I don't feel
> > > too bad about the potential "hit" for reading the file every time the
SP
> > is invoked. But
> > > it is more "clumsy" than just having a static table...
> > >
> > > Thanks for the alternative suggestion -- I'll have to mull it over
> > further! :-)
> > >
> > >
> > > "John Kane" <jt-kane@.comcast.net> wrote in message
> > > news:urIuIDxMEHA.2876@.TK2MSFTNGP09.phx.gbl...
> > > > John,
> > > > A most interesting solution! You would need to use ".ENU" in that
list,
> > then
> > > > the above queries will work with "noise.enu" (US_English). Can I
assume
> > > > you've tried to import the noise word file into a table? For
example:
> > > >
> > > > CREATE TABLE sqlfts_stop_words (
> > > > term nvarchar(50) NOT NULL )
> > > > GO
> > > > ALTER TABLE sqlfts_stop_words ADD
> > > > CONSTRAINT pk_sqlfts_stop_words PRIMARY KEY CLUSTERED (term)
> > > > GO
> > > > -- Alter drive letter and path to noise.enu as appropriate
> > > > BULK INSERT sqlfts_stop_words FROM
> > > > 'F:\MSSQL80\MSSQL\FTDATA\SQLServer\Config\noise.enu'
> > > > GO
> > > >
> > > >
> > > >
> > > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > > news:#p5crXiMEHA.1312@.TK2MSFTNGP12.phx.gbl...
> > > > > I think I've been able to get close with some of this:
> > > > >
> > > > > select * from openrowset('MSDASQL.1', 'Driver={Microsoft Text
Driver
> > > > (*.txt; *.csv)};
> > > > > DefaultDir=C:\Program Files\Common Files\Microsoft
> > > > Shared\MSSearch\Data\Config\;', 'select
> > > > > * from noise.txt')
> > > > >
> > > > > However, this seems to treat the first row as a header row.
> > > > >
> > > > > select * from
> > > > openrowset('Microsoft.Jet.OLEDB.4.0','Text;Database=C:\Program
> > Files\Common
> > > > > Files\Microsoft Shared\MSSearch\Data\Config\;HDR=NO', 'select *
from
> > > > noise.txt')
> > > > >
> > > > > This is the closest I found, and allows me to specify that there
is no
> > > > header row.
> > > > >
> > > > > The only remaining nit is that I *must* have an extension of .TXT.
If
> > I
> > > > try to change
> > > > > "noise.txt" to "noise.eng", I get errors.
> > > > >
> > > > > A colleague of mine discovered that the JET driver has a list of
> > > > "allowable" extensions:
> > > > >
> > > > >
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Extensions
> > > > >
> > > > > My guess is that if I put ".ENG" in that list, then the above
queries
> > will
> > > > work with
> > > > > "noise.eng". I was hoping to avoid modifying the Registry,
though.
> > > > >
> > > > > Does anyone know of a way to circumvent this issue?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > "John Peterson" <j0hnp@.comcast.net> wrote in message
> > > > > news:%23Mz740hMEHA.1388@.TK2MSFTNGP09.phx.gbl...
> > > > > > (SQL Server 2000, SP3a)
> > > > > >
> > > > > > Hello all!
> > > > > >
> > > > > > I'm trying to cobble together something that will let me
reference
> > the
> > > > "noise.eng" (the
> > > > > > English list of the Full Text Search service ignored words)
through
> > > > Transact-SQL.
> > > > > >
> > > > > > I'm trying to reference the "noise.eng" file that's located in:
> > > > > >
> > > > > > C:\Program Files\Common Files\Microsoft
Shared\MSSearch\Data\Config
> > > > > >
> > > > > > There are a couple others in:
> > > > > >
> > > > > > C:\Program Files\Microsoft SQL
Server\MSSQL\FTDATA\SQLServer\Config
> > > > > > C:\windows\SYSTEM32
> > > > > >
> > > > > > but the one in the "Common Files" had the most recent date. :-)
> > > > > >
> > > > > > I *have* had some measure of success with it -- but I'm trying
to
> > come
> > > > up with a
> > > > > "cleaner"
> > > > > > way, if possible.
> > > > > >
> > > > > > This is how I got this to work:
> > > > > >
> > > > > > First I tried setting up a linked server:
> > > > > >
> > > > > > --Create a linked server
> > > > > > execute [dbo].[sp_addlinkedserver]
> > > > > > 'TextTest',
> > > > > > 'Jet 4.0',
> > > > > > 'Microsoft.Jet.OLEDB.4.0',
> > > > > > 'C:\Program Files\Common Files\Microsoft
> > > > Shared\MSSearch\Data\Config',
> > > > > > NULL,
> > > > > > 'Text'
> > > > > > go
> > > > > >
> > > > > > --Set up login mappings
> > > > > > execute [dbo].[sp_addlinkedsrvlogin]
> > > > > > 'TextTest',
> > > > > > FALSE,
> > > > > > NULL,
> > > > > > NULL
> > > > > > go
> > > > > >
> > > > > > Then I checked out the tables that were available:
> > > > > >
> > > > > > --List the tables in the linked server
> > > > > > execute [dbo].[sp_tables_ex] 'TextTest'
> > > > > > go
> > > > > >
> > > > > > Interestingly, all the files in that directory with a .TXT
extension
> > > > were visible as
> > > > > > tables! However, the "noise.eng" file didn't seem to be
available.
> > > > > >
> > > > > > If I copied the "noise.eng" file to "noise.txt", then I could do
> > > > something like:
> > > > > >
> > > > > > select * from TextTest...[noise#txt]
> > > > > >
> > > > > > or
> > > > > >
> > > > > > select * from openquery(TextTest, 'select * from [noise#txt]')
as a
> > > > > >
> > > > > > And that seems to return the information! :-)
> > > > > >
> > > > > > You can clean up the linked servers with:
> > > > > >
> > > > > > execute [dbo].[sp_droplinkedsrvlogin]
> > > > > > 'TextTest', NULL
> > > > > > go
> > > > > >
> > > > > > execute [dbo].[sp_dropserver]
> > > > > > 'TextTest'
> > > > > > go
> > > > > >
> > > > > > However, I'd really like to use the OPENROWSET function if at
all
> > > > possible, and *not*
> > > > > have
> > > > > > to rename/copy the noise.eng file. I was reading that I could
use a
> > > > "schema.ini" file,
> > > > > > and after browsing the web, discovered this format that I
thought
> > might
> > > > work:
> > > > > >
> > > > > > [noise.eng]
> > > > > > ColNameHeader = False
> > > > > > CharacterSet = ANSI
> > > > > > Format = CSVDelimited
> > > > > > Col1=NoiseWord Char Width 100
> > > > > >
> > > > > > Then I tried doing something like:
> > > > > >
> > > > > > select *
> > > > > > from openrowset
> > > > > > (
> > > > > > 'Microsoft.Jet.OLEDB.4.0',
> > > > > > 'Provider=Microsoft.Jet.Oledb.4.0;Data Source=C:\Program
> > Files\Common
> > > > Files\Microsoft
> > > > > > Shared\MSSearch\Data\Config;Extended
> > Properties="text;HDR=No;FMT=CSV";',
> > > > > > 'select * from noise.eng'
> > > > > > ) as a
> > > > > >
> > > > > > Which doesn't quite work -- nor have any of the OPENROWSET
variants
> > I've
> > > > tried. :-(
> > > > > >
> > > > > > I'd like to be able to use OPENROWSET so that I don't have to
create
> > a
> > > > linked server.
> > > > > I'd
> > > > > > also like to avoid copying the "noise.eng" to "noise.txt". I
don't
> > mind
> > > > having to drop
> > > > > in
> > > > > > a "schema.ini" (if that's even necessary/helpful) in that
directory.
> > > > > >
> > > > > > I've found the following URLs to be useful sources of
information:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=eL%23WBktoCHA.1644%40TK2MSFTNGP10&rnum=6
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
http://groups.google.com/groups?q=schema.ini+JET&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=dc2637e5.0206120740.56c9fb53%40posting.google.com&rnum=2
> > > > > >
> > > > > > Sorry for the length of this post, but I sure would be grateful
to
> > > > anyone who might be
> > > > > > able to help! :-)
> > > > > >
> > > > > > John Peterson
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>