PDF Full Text Search

Hi all,

I have a table configured to support Full-Text Search and in this tables a column stores documents of three types, Word, Excel and PDF. Everything works fine with Word and Excel documents.

In order to search PDF documents I've installed "IFilter 5.0", which is published in Acrobat's page, but nothing. What else should I do, is there any other solution?

I've read that I can create a particular filter, so the question is where can find information about creating customized filters? But first, is it a good business to create a new filter?

Thanks in advance.Dear mvargasp,
I have a problem about FTS. I think you could help me...
I wrote to forum but nobody reply to me...

I need your help,
Thanks alot
Yusuf
--------
I've a problem. I'm inexperienced about FTS.
I have a TEXT datatype field in my table and I store MS Word documents.

I want to do full text search on this TEXT datatype field.
So I build catalog and run

"Select * from table where Contains (textfield,'Yusuf')" sql in analyzer.

but null value returns. however I know the table has 3 records.

Anyway, I insert a varchar field in the table and edit my fts catalog.
and then insert 3 records in the table.than rebuild catalog and I try
"Select * from table where Contains (varcharfield,'Yusuf')"
this sql returns true records.

I know that I can FTS in TEXT datatype field but I can't. I don't know why.
I need your help.
thanks alot

Yusuf|||Hi Yusuf,

It seems that you have created a catalog and rebuild it then, but you have not populate it. So What you must do after you create or rebuild a catalog is to populate it. I order to do so, you must right click your catalog in the Enterprise Manager and then click Populate.

After this the FTS must work.

God Bless.

Password protection

Basic, I know.....
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.

Password protection

Basic, I know.....
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".
Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>
|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.

Password protection

Basic, I know.....
I am migrating an application from Jet to SQL (MSDE). The
database stores user ID and passords for the application.
When designing a table in SQL, ho do I st the password
field to be not viewable as in Jet it is called "password".Hi,
Why dont you use the SQL Server Login and Users. The password column is
encryted and can not be decrypted (Highly secured).
See the topic "Managing security" in SQL server books online.
Thanks
Hari
MCDBA
"Keith Emery" <anonymous@.discussions.microsoft.com> wrote in message
news:79b501c4843f$e8a6d430$a601280a@.phx.gbl...
> Basic, I know.....
> I am migrating an application from Jet to SQL (MSDE). The
> database stores user ID and passords for the application.
> When designing a table in SQL, ho do I st the password
> field to be not viewable as in Jet it is called "password".
>|||Hari's suggestion is valid. Let SQL Server (MSDE) manage security for you.
It gives you one less thing to worry about.
Rand
This posting is provided "as is" with no warranties and confers no rights.

Password hashes for SQL 7.0 & 2000

hi,
The password hashes generated by pwdencrypt() for SQL7.0 & SQL2000 are
different. The password hash generated for SQL 2000 stores both the actual
passsword & it's upper case version (David Litchfield's article on cracking
SQL passwords). But the passwor hash for SQL 7.0 is of 16 bytes only. I
wanted to use the pwdencrypt() to generate the password hashes but want to
verify the values without sending the 'pwdcompare()' query to server. I
could do it for SQL 2000 but the SQL 7.0 hashes seems to be different.
Thanks.
Ajey.Those undocumented xp shouldn't be used in production. They're not supported
and subject to change by MS without notice (which has been changed in the
past). If you're looking a way to hash your password, take a look at this
udf (courtesy of Steve Kass).
http://groups.google.co.uk/groups?q...58-E7ADEA79360F
-oj
"Ajey" <ajey5@.hotmail.com> wrote in message
news:OuaWKJ2BFHA.2568@.TK2MSFTNGP10.phx.gbl...
> hi,
> The password hashes generated by pwdencrypt() for SQL7.0 & SQL2000 are
> different. The password hash generated for SQL 2000 stores both the actual
> passsword & it's upper case version (David Litchfield's article on
> cracking
> SQL passwords). But the passwor hash for SQL 7.0 is of 16 bytes only. I
> wanted to use the pwdencrypt() to generate the password hashes but want to
> verify the values without sending the 'pwdcompare()' query to server. I
> could do it for SQL 2000 but the SQL 7.0 hashes seems to be different.
> Thanks.
> Ajey.
>