Full text search workaround?

Me and a friend are setting up a .net project on a shared hosting server....the thing is, they dont seem to allow the use of full text search....when i connect to the server on Enterprise Manager, the option for "Create new catalog" is disabled.

we need to give users the ability to search by keywords......what's a good workaround for this without using FTS?

any advice?

thanks.

G.Create queries that use the wildcart % for all the fields you want to search in ...
Only way you can do it ...|||Here is a nice example of some searching logic.

http://weblogs.sqlteam.com/jeffs/archive/2004/11/02/2460.aspx|||

% wildcards work really slow u should be carefull...

find a way to use full text search.

sql

Full text 4Gb memory

I have a server run std edition 2000 with FTS. The server has 4Gb of memory
is there any benefit in setting the 3Gb switch?
The /3GB switch refers to the Virtual Address Space for any process, not
just SQL Server. Whether or not that space is backed by physical ram is
dependent on the configuration of the server and other applications running
at any particular time. Let's say you have 2 GB of ram and a 4 GB swap
file. Then, it is possible for an application to have, say 1 GB of physical
ram for kernel mode processing, 1 GB of physical ram for a portion of the
user mode processing, then the application could use of to 2 GB of swap
space. The allocation of that swap space would be dependent on the /3GB
switch being enabled or not.
The same goes for physical ram. If you have 4 GB, then it is possible that
one application could be allocated 1 GB for kernel mode, and 3 GB for user
mode. The problem is that this is not the only application on the server.
If anything, the OS has to be running, mostly from critical sections of
physical ram.
Now, SQL Server 2K Standard Edition will only allocate a MAXIMUM of 2 GB for
the Buffer Pool. As SS2K SE is an application, it could use 1 GB to 2 GB
for the kernel mode requests, but the Buffer Pool is not the ONLY space SS
uses. So, by using the /3GB switch, you could dedicate a 2 GB Buffer Pool
and still allow up to 1 GB for kernel mode requests and 1 GB for MEM TO
LEAVE sections of memory, all backed by physical ram. To the extent that
other applications and the OS itself requires physical ram, you could still
maintain a 2 GB Buffer Pool backed by physical ram and allow the kernel mode
and MEM TO LEAVE regions to be swapped out to the page file.
So, yes, there could be benefits to using the /3GB switch.
However, you never said what OS version you were running on. Neither Win2K
SE nor Win2K3 SE support the /3GB boot.ini parameter. You have to be
running Win2K AS or Win2K3 EE or either of the Data Center Editions.
Sincerely,
Anthony Thomas

"Simon" <Simon@.cmg.noemail> wrote in message
news:07DDD724-0C42-4748-A82F-5C41DE2AD5D4@.microsoft.com...
I have a server run std edition 2000 with FTS. The server has 4Gb of memory
is there any benefit in setting the 3Gb switch?

Full text 4Gb memory

I have a server run std edition 2000 with FTS. The server has 4Gb of memory
is there any benefit in setting the 3Gb switch?The /3GB switch refers to the Virtual Address Space for any process, not
just SQL Server. Whether or not that space is backed by physical ram is
dependent on the configuration of the server and other applications running
at any particular time. Let's say you have 2 GB of ram and a 4 GB swap
file. Then, it is possible for an application to have, say 1 GB of physical
ram for kernel mode processing, 1 GB of physical ram for a portion of the
user mode processing, then the application could use of to 2 GB of swap
space. The allocation of that swap space would be dependent on the /3GB
switch being enabled or not.
The same goes for physical ram. If you have 4 GB, then it is possible that
one application could be allocated 1 GB for kernel mode, and 3 GB for user
mode. The problem is that this is not the only application on the server.
If anything, the OS has to be running, mostly from critical sections of
physical ram.
Now, SQL Server 2K Standard Edition will only allocate a MAXIMUM of 2 GB for
the Buffer Pool. As SS2K SE is an application, it could use 1 GB to 2 GB
for the kernel mode requests, but the Buffer Pool is not the ONLY space SS
uses. So, by using the /3GB switch, you could dedicate a 2 GB Buffer Pool
and still allow up to 1 GB for kernel mode requests and 1 GB for MEM TO
LEAVE sections of memory, all backed by physical ram. To the extent that
other applications and the OS itself requires physical ram, you could still
maintain a 2 GB Buffer Pool backed by physical ram and allow the kernel mode
and MEM TO LEAVE regions to be swapped out to the page file.
So, yes, there could be benefits to using the /3GB switch.
However, you never said what OS version you were running on. Neither Win2K
SE nor Win2K3 SE support the /3GB boot.ini parameter. You have to be
running Win2K AS or Win2K3 EE or either of the Data Center Editions.
Sincerely,
Anthony Thomas
"Simon" <Simon@.cmg.noemail> wrote in message
news:07DDD724-0C42-4748-A82F-5C41DE2AD5D4@.microsoft.com...
I have a server run std edition 2000 with FTS. The server has 4Gb of memory
is there any benefit in setting the 3Gb switch?

Full text 4Gb memory

I have a server run std edition 2000 with FTS. The server has 4Gb of memory
is there any benefit in setting the 3Gb switch?The /3GB switch refers to the Virtual Address Space for any process, not
just SQL Server. Whether or not that space is backed by physical ram is
dependent on the configuration of the server and other applications running
at any particular time. Let's say you have 2 GB of ram and a 4 GB swap
file. Then, it is possible for an application to have, say 1 GB of physical
ram for kernel mode processing, 1 GB of physical ram for a portion of the
user mode processing, then the application could use of to 2 GB of swap
space. The allocation of that swap space would be dependent on the /3GB
switch being enabled or not.
The same goes for physical ram. If you have 4 GB, then it is possible that
one application could be allocated 1 GB for kernel mode, and 3 GB for user
mode. The problem is that this is not the only application on the server.
If anything, the OS has to be running, mostly from critical sections of
physical ram.
Now, SQL Server 2K Standard Edition will only allocate a MAXIMUM of 2 GB for
the Buffer Pool. As SS2K SE is an application, it could use 1 GB to 2 GB
for the kernel mode requests, but the Buffer Pool is not the ONLY space SS
uses. So, by using the /3GB switch, you could dedicate a 2 GB Buffer Pool
and still allow up to 1 GB for kernel mode requests and 1 GB for MEM TO
LEAVE sections of memory, all backed by physical ram. To the extent that
other applications and the OS itself requires physical ram, you could still
maintain a 2 GB Buffer Pool backed by physical ram and allow the kernel mode
and MEM TO LEAVE regions to be swapped out to the page file.
So, yes, there could be benefits to using the /3GB switch.
However, you never said what OS version you were running on. Neither Win2K
SE nor Win2K3 SE support the /3GB boot.ini parameter. You have to be
running Win2K AS or Win2K3 EE or either of the Data Center Editions.
Sincerely,
Anthony Thomas
"Simon" <Simon@.cmg.noemail> wrote in message
news:07DDD724-0C42-4748-A82F-5C41DE2AD5D4@.microsoft.com...
I have a server run std edition 2000 with FTS. The server has 4Gb of memory
is there any benefit in setting the 3Gb switch?

Full Log Setting

I've confused myself. If you're doing log backups and you
have of course the database option set to FULL, then how
can your logs ever shrink? I understand that after the
log backup happens technically the logs can shrink w/o
risk of losing data in the logs. But what actually
shrinks these logs? Autoshrink won't do it, will it? Do
you have run something manuall?
Please refer to Tibor's link
http://www.karaszi.com/sqlserver/info_dont_shrink.asp
Jeff Duncan
MCDBA, MCSE+I
"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in message
news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
> I've confused myself. If you're doing log backups and you
> have of course the database option set to FULL, then how
> can your logs ever shrink? I understand that after the
> log backup happens technically the logs can shrink w/o
> risk of losing data in the logs. But what actually
> shrinks these logs? Autoshrink won't do it, will it? Do
> you have run something manuall?
>
|||Thx for the link, but I'm getting more confused (which is
probably a good sign):
If I'm doing log backups and have FULL on, can I ever get
these logs shrunk w/o using Tibor's specialized shrink
code?

>--Original Message--
>Please refer to Tibor's link
>http://www.karaszi.com/sqlserver/info_dont_shrink.asp
>
>--
>Jeff Duncan
>MCDBA, MCSE+I
>"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
you[vbcol=seagreen]
Do
>
>.
>
|||There's no shrink code on that page. The code is only there to prove that when you shrink a data file, the
same amount of data is logged to the tlog.
If you do both full and log backup, then the log backups will empty the files. To shrink the files, you need
to either have autoshrink, or execute DBCC SHRINKFILE or DBCC SHRINKDB. But please read the section about
virtual log files and the log file has to be empty at the end.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
<anonymous@.discussions.microsoft.com> wrote in message news:905a01c432ed$d176ac70$a301280a@.phx.gbl...[vbcol=seagreen]
> Thx for the link, but I'm getting more confused (which is
> probably a good sign):
> If I'm doing log backups and have FULL on, can I ever get
> these logs shrunk w/o using Tibor's specialized shrink
> code?
> message
> you
> Do

Full Log Setting

I've confused myself. If you're doing log backups and you
have of course the database option set to FULL, then how
can your logs ever shrink? I understand that after the
log backup happens technically the logs can shrink w/o
risk of losing data in the logs. But what actually
shrinks these logs? Autoshrink won't do it, will it? Do
you have run something manuall?Please refer to Tibor's link
http://www.karaszi.com/sqlserver/info_dont_shrink.asp
Jeff Duncan
MCDBA, MCSE+I
"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in message
news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
> I've confused myself. If you're doing log backups and you
> have of course the database option set to FULL, then how
> can your logs ever shrink? I understand that after the
> log backup happens technically the logs can shrink w/o
> risk of losing data in the logs. But what actually
> shrinks these logs? Autoshrink won't do it, will it? Do
> you have run something manuall?
>|||Thx for the link, but I'm getting more confused (which is
probably a good sign):
If I'm doing log backups and have FULL on, can I ever get
these logs shrunk w/o using Tibor's specialized shrink
code?
>--Original Message--
>Please refer to Tibor's link
>http://www.karaszi.com/sqlserver/info_dont_shrink.asp
>
>--
>Jeff Duncan
>MCDBA, MCSE+I
>"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in
message
>news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
>> I've confused myself. If you're doing log backups and
you
>> have of course the database option set to FULL, then how
>> can your logs ever shrink? I understand that after the
>> log backup happens technically the logs can shrink w/o
>> risk of losing data in the logs. But what actually
>> shrinks these logs? Autoshrink won't do it, will it?
Do
>> you have run something manuall?
>
>.
>|||There's no shrink code on that page. The code is only there to prove that when you shrink a data file, the
same amount of data is logged to the tlog.
If you do both full and log backup, then the log backups will empty the files. To shrink the files, you need
to either have autoshrink, or execute DBCC SHRINKFILE or DBCC SHRINKDB. But please read the section about
virtual log files and the log file has to be empty at the end.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
<anonymous@.discussions.microsoft.com> wrote in message news:905a01c432ed$d176ac70$a301280a@.phx.gbl...
> Thx for the link, but I'm getting more confused (which is
> probably a good sign):
> If I'm doing log backups and have FULL on, can I ever get
> these logs shrunk w/o using Tibor's specialized shrink
> code?
> >--Original Message--
> >Please refer to Tibor's link
> >
> >http://www.karaszi.com/sqlserver/info_dont_shrink.asp
> >
> >
> >--
> >Jeff Duncan
> >MCDBA, MCSE+I
> >"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in
> message
> >news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
> >> I've confused myself. If you're doing log backups and
> you
> >> have of course the database option set to FULL, then how
> >> can your logs ever shrink? I understand that after the
> >> log backup happens technically the logs can shrink w/o
> >> risk of losing data in the logs. But what actually
> >> shrinks these logs? Autoshrink won't do it, will it?
> Do
> >> you have run something manuall?
> >>
> >
> >
> >.
> >

Full Log Setting

I've confused myself. If you're doing log backups and you
have of course the database option set to FULL, then how
can your logs ever shrink? I understand that after the
log backup happens technically the logs can shrink w/o
risk of losing data in the logs. But what actually
shrinks these logs? Autoshrink won't do it, will it? Do
you have run something manuall?Please refer to Tibor's link
http://www.karaszi.com/sqlserver/info_dont_shrink.asp
Jeff Duncan
MCDBA, MCSE+I
"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in message
news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
> I've confused myself. If you're doing log backups and you
> have of course the database option set to FULL, then how
> can your logs ever shrink? I understand that after the
> log backup happens technically the logs can shrink w/o
> risk of losing data in the logs. But what actually
> shrinks these logs? Autoshrink won't do it, will it? Do
> you have run something manuall?
>|||Thx for the link, but I'm getting more confused (which is
probably a good sign):
If I'm doing log backups and have FULL on, can I ever get
these logs shrunk w/o using Tibor's specialized shrink
code?

>--Original Message--
>Please refer to Tibor's link
>http://www.karaszi.com/sqlserver/info_dont_shrink.asp
>
>--
>Jeff Duncan
>MCDBA, MCSE+I
>"bzkdfl" <anonymous@.discussions.microsoft.com> wrote in
message
>news:8ed101c432de$bb0a7610$a101280a@.phx.gbl...
you[vbcol=seagreen]
Do[vbcol=seagreen]
>
>.
>|||There's no shrink code on that page. The code is only there to prove that wh
en you shrink a data file, the
same amount of data is logged to the tlog.
If you do both full and log backup, then the log backups will empty the file
s. To shrink the files, you need
to either have autoshrink, or execute DBCC SHRINKFILE or DBCC SHRINKDB. But
please read the section about
virtual log files and the log file has to be empty at the end.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
<anonymous@.discussions.microsoft.com> wrote in message news:905a01c432ed$d176ac70$a301280a@.p
hx.gbl...[vbcol=seagreen]
> Thx for the link, but I'm getting more confused (which is
> probably a good sign):
> If I'm doing log backups and have FULL on, can I ever get
> these logs shrunk w/o using Tibor's specialized shrink
> code?
>
> message
> you
> Do