Hi,
I read that we can optimise from 10 to 15 % the performance of a replication
by changing the default value of the HistoryVerboseLevel and the
OutputVerboseLevel of the Agent Profiles
For exemple for the Distribution Agent we have to use
distrib -HistoryVerboseLevel 1
distrib -OutputVerboseLevel 0
The default value are 2 for both
The distrib program to executable is in
C:\Program Files\Microsoft SQL Server\80\COM
2 questions
01- On which server I have to execute this command on the Distributor or
on the
Publisher
02- Also when i go on the Distributor and view the propreties of the Agent
profile
I dont see the OutputVerboseLevel. Is that normal
Thanks in advance !
With a remote publisher/distributor its on the distributor, with a local
publisher/distributor its on the publisher.
Basically you do it wherever your distribution agents run.
Its normal for the OutputVerboseLevel parameter not to be used.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"GC" <GC@.discussions.microsoft.com> wrote in message
news:9B8F89FB-1106-48F2-9ED6-AC2BC752333B@.microsoft.com...
> Hi,
> I read that we can optimise from 10 to 15 % the performance of a
> replication
> by changing the default value of the HistoryVerboseLevel and the
> OutputVerboseLevel of the Agent Profiles
> For exemple for the Distribution Agent we have to use
> distrib -HistoryVerboseLevel 1
> distrib -OutputVerboseLevel 0
> The default value are 2 for both
> The distrib program to executable is in
> C:\Program Files\Microsoft SQL Server\80\COM
> 2 questions
> 01- On which server I have to execute this command on the Distributor or
> on the
> Publisher
> 02- Also when i go on the Distributor and view the propreties of the
> Agent
> profile
> I dont see the OutputVerboseLevel. Is that normal
> Thanks in advance !
>
>
>
>
>
>
>
>
>
Showing posts with label value. Show all posts
Showing posts with label value. Show all posts
Monday, March 12, 2012
Optimally setting a FillFactor value
A general question in optimally adjusting a FillFactor setting on an index.
Let's hypothetically say I have a index with a FillFactor = 90.
Again let's hypothetically say it has been 7 days since this index was last
rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
index has an avg_fragmentation_in_percent = 25.0.
I perform the following on the index, changing the FillFactor from 90 to 85:
ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
REBUILD WITH ( FILLFACTOR = 85 )
Let's hypothetically say that it is now 7 days since this index was last
rebuilt with a FillFactor = 85.
Let's also hypothetically say that the same number and exact types of DML
statements occurred on the table where this index resides during this past 7
days as during the 7 day period when the index had a FillFactor = 90.
Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
with the FillFactor = 85) and this particular index has an
avg_fragmentation_in_percent = 40.0.
In optimally setting the FillFactor for this hypothetical index, from the
above findings I would conclude that a FillFactor = 90 is a more otpimal
setting for the index than a FillFactor = 85. Correct?
The next step in finding the optimal FillFactor setting might be to increase
the FillFactor = 95 and see how the fragmentation compares to when the
FillFactor = 90. Correct?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200708/1
The approach you outlined is good and is typical of how one goes about
finding the optimal fill factor. But you really have it backwards from most
real life scenarios. Usually if the fragmentation goes up the fill factor
needs to come down. Fragmentation is mostly due to page splits that happen
when the pages are too full to handle the new rows that need to go on a
particular page. When there isn't room the page must split and that causes
fragmentation. So by decreasing the fill factor you leave more room on the
page and reduce the chance the page will split before the next reindex
occurs. The trick is to balance the splits (or fragmentation) with the
fullness of the pages. If you reduce the fill factor too much you end up
with lots of partially filled pages. That increases the I/O since it
requires more reads to read the same data for pages that are partially full
vs. totally full. Don't get too hung up on the amount of fragmentation. You
can spend a lot of time fine tuning a fill factor for little extra gain.
Don't tweak too many times as close is good enough. For a typical OLTP app
fragmentation is not as critical since you are reading one row at a time and
it takes just as long to read a single page regardless of where it is in the
file. Just keep the pages as full as possible while reducing but not
necessarily eliminating page splits.Where as range scans (frequently found
in OLAP) will be greatly hindered by high values of fragmentation.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:76a6c0d915019@.uwe...
>A general question in optimally adjusting a FillFactor setting on an index.
> Let's hypothetically say I have a index with a FillFactor = 90.
> Again let's hypothetically say it has been 7 days since this index was
> last
> rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
> index has an avg_fragmentation_in_percent = 25.0.
> I perform the following on the index, changing the FillFactor from 90 to
> 85:
> ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
> REBUILD WITH ( FILLFACTOR = 85 )
> Let's hypothetically say that it is now 7 days since this index was last
> rebuilt with a FillFactor = 85.
> Let's also hypothetically say that the same number and exact types of DML
> statements occurred on the table where this index resides during this past
> 7
> days as during the 7 day period when the index had a FillFactor = 90.
> Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
> with the FillFactor = 85) and this particular index has an
> avg_fragmentation_in_percent = 40.0.
> In optimally setting the FillFactor for this hypothetical index, from the
> above findings I would conclude that a FillFactor = 90 is a more otpimal
> setting for the index than a FillFactor = 85. Correct?
> The next step in finding the optimal FillFactor setting might be to
> increase
> the FillFactor = 95 and see how the fragmentation compares to when the
> FillFactor = 90. Correct?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200708/1
>
Let's hypothetically say I have a index with a FillFactor = 90.
Again let's hypothetically say it has been 7 days since this index was last
rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
index has an avg_fragmentation_in_percent = 25.0.
I perform the following on the index, changing the FillFactor from 90 to 85:
ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
REBUILD WITH ( FILLFACTOR = 85 )
Let's hypothetically say that it is now 7 days since this index was last
rebuilt with a FillFactor = 85.
Let's also hypothetically say that the same number and exact types of DML
statements occurred on the table where this index resides during this past 7
days as during the 7 day period when the index had a FillFactor = 90.
Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
with the FillFactor = 85) and this particular index has an
avg_fragmentation_in_percent = 40.0.
In optimally setting the FillFactor for this hypothetical index, from the
above findings I would conclude that a FillFactor = 90 is a more otpimal
setting for the index than a FillFactor = 85. Correct?
The next step in finding the optimal FillFactor setting might be to increase
the FillFactor = 95 and see how the fragmentation compares to when the
FillFactor = 90. Correct?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200708/1
The approach you outlined is good and is typical of how one goes about
finding the optimal fill factor. But you really have it backwards from most
real life scenarios. Usually if the fragmentation goes up the fill factor
needs to come down. Fragmentation is mostly due to page splits that happen
when the pages are too full to handle the new rows that need to go on a
particular page. When there isn't room the page must split and that causes
fragmentation. So by decreasing the fill factor you leave more room on the
page and reduce the chance the page will split before the next reindex
occurs. The trick is to balance the splits (or fragmentation) with the
fullness of the pages. If you reduce the fill factor too much you end up
with lots of partially filled pages. That increases the I/O since it
requires more reads to read the same data for pages that are partially full
vs. totally full. Don't get too hung up on the amount of fragmentation. You
can spend a lot of time fine tuning a fill factor for little extra gain.
Don't tweak too many times as close is good enough. For a typical OLTP app
fragmentation is not as critical since you are reading one row at a time and
it takes just as long to read a single page regardless of where it is in the
file. Just keep the pages as full as possible while reducing but not
necessarily eliminating page splits.Where as range scans (frequently found
in OLAP) will be greatly hindered by high values of fragmentation.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:76a6c0d915019@.uwe...
>A general question in optimally adjusting a FillFactor setting on an index.
> Let's hypothetically say I have a index with a FillFactor = 90.
> Again let's hypothetically say it has been 7 days since this index was
> last
> rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
> index has an avg_fragmentation_in_percent = 25.0.
> I perform the following on the index, changing the FillFactor from 90 to
> 85:
> ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
> REBUILD WITH ( FILLFACTOR = 85 )
> Let's hypothetically say that it is now 7 days since this index was last
> rebuilt with a FillFactor = 85.
> Let's also hypothetically say that the same number and exact types of DML
> statements occurred on the table where this index resides during this past
> 7
> days as during the 7 day period when the index had a FillFactor = 90.
> Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
> with the FillFactor = 85) and this particular index has an
> avg_fragmentation_in_percent = 40.0.
> In optimally setting the FillFactor for this hypothetical index, from the
> above findings I would conclude that a FillFactor = 90 is a more otpimal
> setting for the index than a FillFactor = 85. Correct?
> The next step in finding the optimal FillFactor setting might be to
> increase
> the FillFactor = 95 and see how the fragmentation compares to when the
> FillFactor = 90. Correct?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200708/1
>
Optimally setting a FillFactor value
A general question in optimally adjusting a FillFactor setting on an index.
Let's hypothetically say I have a index with a FillFactor = 90.
Again let's hypothetically say it has been 7 days since this index was last
rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
index has an avg_fragmentation_in_percent = 25.0.
I perform the following on the index, changing the FillFactor from 90 to 85:
ALTER INDEX [name of index] ON [name of database].dbo.[name of t
able]
REBUILD WITH ( FILLFACTOR = 85 )
Let's hypothetically say that it is now 7 days since this index was last
rebuilt with a FillFactor = 85.
Let's also hypothetically say that the same number and exact types of DML
statements occurred on the table where this index resides during this past 7
days as during the 7 day period when the index had a FillFactor = 90.
Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
with the FillFactor = 85) and this particular index has an
avg_fragmentation_in_percent = 40.0.
In optimally setting the FillFactor for this hypothetical index, from the
above findings I would conclude that a FillFactor = 90 is a more otpimal
setting for the index than a FillFactor = 85. Correct?
The next step in finding the optimal FillFactor setting might be to increase
the FillFactor = 95 and see how the fragmentation compares to when the
FillFactor = 90. Correct?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200708/1The approach you outlined is good and is typical of how one goes about
finding the optimal fill factor. But you really have it backwards from most
real life scenarios. Usually if the fragmentation goes up the fill factor
needs to come down. Fragmentation is mostly due to page splits that happen
when the pages are too full to handle the new rows that need to go on a
particular page. When there isn't room the page must split and that causes
fragmentation. So by decreasing the fill factor you leave more room on the
page and reduce the chance the page will split before the next reindex
occurs. The trick is to balance the splits (or fragmentation) with the
fullness of the pages. If you reduce the fill factor too much you end up
with lots of partially filled pages. That increases the I/O since it
requires more reads to read the same data for pages that are partially full
vs. totally full. Don't get too hung up on the amount of fragmentation. You
can spend a lot of time fine tuning a fill factor for little extra gain.
Don't tweak too many times as close is good enough. For a typical OLTP app
fragmentation is not as critical since you are reading one row at a time and
it takes just as long to read a single page regardless of where it is in the
file. Just keep the pages as full as possible while reducing but not
necessarily eliminating page splits.Where as range scans (frequently found
in OLAP) will be greatly hindered by high values of fragmentation.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:76a6c0d915019@.uwe...
>A general question in optimally adjusting a FillFactor setting on an index.
> Let's hypothetically say I have a index with a FillFactor = 90.
> Again let's hypothetically say it has been 7 days since this index was
> last
> rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
> index has an avg_fragmentation_in_percent = 25.0.
> I perform the following on the index, changing the FillFactor from 90 to
> 85:
> ALTER INDEX [name of index] ON [name of database].dbo.[name of
table]
> REBUILD WITH ( FILLFACTOR = 85 )
> Let's hypothetically say that it is now 7 days since this index was last
> rebuilt with a FillFactor = 85.
> Let's also hypothetically say that the same number and exact types of DML
> statements occurred on the table where this index resides during this past
> 7
> days as during the 7 day period when the index had a FillFactor = 90.
> Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
> with the FillFactor = 85) and this particular index has an
> avg_fragmentation_in_percent = 40.0.
> In optimally setting the FillFactor for this hypothetical index, from the
> above findings I would conclude that a FillFactor = 90 is a more otpimal
> setting for the index than a FillFactor = 85. Correct?
> The next step in finding the optimal FillFactor setting might be to
> increase
> the FillFactor = 95 and see how the fragmentation compares to when the
> FillFactor = 90. Correct?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200708/1
>
Let's hypothetically say I have a index with a FillFactor = 90.
Again let's hypothetically say it has been 7 days since this index was last
rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
index has an avg_fragmentation_in_percent = 25.0.
I perform the following on the index, changing the FillFactor from 90 to 85:
ALTER INDEX [name of index] ON [name of database].dbo.[name of t
able]
REBUILD WITH ( FILLFACTOR = 85 )
Let's hypothetically say that it is now 7 days since this index was last
rebuilt with a FillFactor = 85.
Let's also hypothetically say that the same number and exact types of DML
statements occurred on the table where this index resides during this past 7
days as during the 7 day period when the index had a FillFactor = 90.
Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
with the FillFactor = 85) and this particular index has an
avg_fragmentation_in_percent = 40.0.
In optimally setting the FillFactor for this hypothetical index, from the
above findings I would conclude that a FillFactor = 90 is a more otpimal
setting for the index than a FillFactor = 85. Correct?
The next step in finding the optimal FillFactor setting might be to increase
the FillFactor = 95 and see how the fragmentation compares to when the
FillFactor = 90. Correct?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200708/1The approach you outlined is good and is typical of how one goes about
finding the optimal fill factor. But you really have it backwards from most
real life scenarios. Usually if the fragmentation goes up the fill factor
needs to come down. Fragmentation is mostly due to page splits that happen
when the pages are too full to handle the new rows that need to go on a
particular page. When there isn't room the page must split and that causes
fragmentation. So by decreasing the fill factor you leave more room on the
page and reduce the chance the page will split before the next reindex
occurs. The trick is to balance the splits (or fragmentation) with the
fullness of the pages. If you reduce the fill factor too much you end up
with lots of partially filled pages. That increases the I/O since it
requires more reads to read the same data for pages that are partially full
vs. totally full. Don't get too hung up on the amount of fragmentation. You
can spend a lot of time fine tuning a fill factor for little extra gain.
Don't tweak too many times as close is good enough. For a typical OLTP app
fragmentation is not as critical since you are reading one row at a time and
it takes just as long to read a single page regardless of where it is in the
file. Just keep the pages as full as possible while reducing but not
necessarily eliminating page splits.Where as range scans (frequently found
in OLAP) will be greatly hindered by high values of fragmentation.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:76a6c0d915019@.uwe...
>A general question in optimally adjusting a FillFactor setting on an index.
> Let's hypothetically say I have a index with a FillFactor = 90.
> Again let's hypothetically say it has been 7 days since this index was
> last
> rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
> index has an avg_fragmentation_in_percent = 25.0.
> I perform the following on the index, changing the FillFactor from 90 to
> 85:
> ALTER INDEX [name of index] ON [name of database].dbo.[name of
table]
> REBUILD WITH ( FILLFACTOR = 85 )
> Let's hypothetically say that it is now 7 days since this index was last
> rebuilt with a FillFactor = 85.
> Let's also hypothetically say that the same number and exact types of DML
> statements occurred on the table where this index resides during this past
> 7
> days as during the 7 day period when the index had a FillFactor = 90.
> Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
> with the FillFactor = 85) and this particular index has an
> avg_fragmentation_in_percent = 40.0.
> In optimally setting the FillFactor for this hypothetical index, from the
> above findings I would conclude that a FillFactor = 90 is a more otpimal
> setting for the index than a FillFactor = 85. Correct?
> The next step in finding the optimal FillFactor setting might be to
> increase
> the FillFactor = 95 and see how the fragmentation compares to when the
> FillFactor = 90. Correct?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200708/1
>
Optimally setting a FillFactor value
A general question in optimally adjusting a FillFactor setting on an index.
Let's hypothetically say I have a index with a FillFactor = 90.
Again let's hypothetically say it has been 7 days since this index was last
rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
index has an avg_fragmentation_in_percent = 25.0.
I perform the following on the index, changing the FillFactor from 90 to 85:
ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
REBUILD WITH ( FILLFACTOR = 85 )
Let's hypothetically say that it is now 7 days since this index was last
rebuilt with a FillFactor = 85.
Let's also hypothetically say that the same number and exact types of DML
statements occurred on the table where this index resides during this past 7
days as during the 7 day period when the index had a FillFactor = 90.
Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
with the FillFactor = 85) and this particular index has an
avg_fragmentation_in_percent = 40.0.
In optimally setting the FillFactor for this hypothetical index, from the
above findings I would conclude that a FillFactor = 90 is a more otpimal
setting for the index than a FillFactor = 85. Correct?
The next step in finding the optimal FillFactor setting might be to increase
the FillFactor = 95 and see how the fragmentation compares to when the
FillFactor = 90. Correct?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200708/1The approach you outlined is good and is typical of how one goes about
finding the optimal fill factor. But you really have it backwards from most
real life scenarios. Usually if the fragmentation goes up the fill factor
needs to come down. Fragmentation is mostly due to page splits that happen
when the pages are too full to handle the new rows that need to go on a
particular page. When there isn't room the page must split and that causes
fragmentation. So by decreasing the fill factor you leave more room on the
page and reduce the chance the page will split before the next reindex
occurs. The trick is to balance the splits (or fragmentation) with the
fullness of the pages. If you reduce the fill factor too much you end up
with lots of partially filled pages. That increases the I/O since it
requires more reads to read the same data for pages that are partially full
vs. totally full. Don't get too hung up on the amount of fragmentation. You
can spend a lot of time fine tuning a fill factor for little extra gain.
Don't tweak too many times as close is good enough. For a typical OLTP app
fragmentation is not as critical since you are reading one row at a time and
it takes just as long to read a single page regardless of where it is in the
file. Just keep the pages as full as possible while reducing but not
necessarily eliminating page splits.Where as range scans (frequently found
in OLAP) will be greatly hindered by high values of fragmentation.
--
Andrew J. Kelly SQL MVP
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:76a6c0d915019@.uwe...
>A general question in optimally adjusting a FillFactor setting on an index.
> Let's hypothetically say I have a index with a FillFactor = 90.
> Again let's hypothetically say it has been 7 days since this index was
> last
> rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
> index has an avg_fragmentation_in_percent = 25.0.
> I perform the following on the index, changing the FillFactor from 90 to
> 85:
> ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
> REBUILD WITH ( FILLFACTOR = 85 )
> Let's hypothetically say that it is now 7 days since this index was last
> rebuilt with a FillFactor = 85.
> Let's also hypothetically say that the same number and exact types of DML
> statements occurred on the table where this index resides during this past
> 7
> days as during the 7 day period when the index had a FillFactor = 90.
> Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
> with the FillFactor = 85) and this particular index has an
> avg_fragmentation_in_percent = 40.0.
> In optimally setting the FillFactor for this hypothetical index, from the
> above findings I would conclude that a FillFactor = 90 is a more otpimal
> setting for the index than a FillFactor = 85. Correct?
> The next step in finding the optimal FillFactor setting might be to
> increase
> the FillFactor = 95 and see how the fragmentation compares to when the
> FillFactor = 90. Correct?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200708/1
>
Let's hypothetically say I have a index with a FillFactor = 90.
Again let's hypothetically say it has been 7 days since this index was last
rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
index has an avg_fragmentation_in_percent = 25.0.
I perform the following on the index, changing the FillFactor from 90 to 85:
ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
REBUILD WITH ( FILLFACTOR = 85 )
Let's hypothetically say that it is now 7 days since this index was last
rebuilt with a FillFactor = 85.
Let's also hypothetically say that the same number and exact types of DML
statements occurred on the table where this index resides during this past 7
days as during the 7 day period when the index had a FillFactor = 90.
Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
with the FillFactor = 85) and this particular index has an
avg_fragmentation_in_percent = 40.0.
In optimally setting the FillFactor for this hypothetical index, from the
above findings I would conclude that a FillFactor = 90 is a more otpimal
setting for the index than a FillFactor = 85. Correct?
The next step in finding the optimal FillFactor setting might be to increase
the FillFactor = 95 and see how the fragmentation compares to when the
FillFactor = 90. Correct?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200708/1The approach you outlined is good and is typical of how one goes about
finding the optimal fill factor. But you really have it backwards from most
real life scenarios. Usually if the fragmentation goes up the fill factor
needs to come down. Fragmentation is mostly due to page splits that happen
when the pages are too full to handle the new rows that need to go on a
particular page. When there isn't room the page must split and that causes
fragmentation. So by decreasing the fill factor you leave more room on the
page and reduce the chance the page will split before the next reindex
occurs. The trick is to balance the splits (or fragmentation) with the
fullness of the pages. If you reduce the fill factor too much you end up
with lots of partially filled pages. That increases the I/O since it
requires more reads to read the same data for pages that are partially full
vs. totally full. Don't get too hung up on the amount of fragmentation. You
can spend a lot of time fine tuning a fill factor for little extra gain.
Don't tweak too many times as close is good enough. For a typical OLTP app
fragmentation is not as critical since you are reading one row at a time and
it takes just as long to read a single page regardless of where it is in the
file. Just keep the pages as full as possible while reducing but not
necessarily eliminating page splits.Where as range scans (frequently found
in OLAP) will be greatly hindered by high values of fragmentation.
--
Andrew J. Kelly SQL MVP
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:76a6c0d915019@.uwe...
>A general question in optimally adjusting a FillFactor setting on an index.
> Let's hypothetically say I have a index with a FillFactor = 90.
> Again let's hypothetically say it has been 7 days since this index was
> last
> rebuilt. I query master.sys.dm_db_index_physical_stats and this particular
> index has an avg_fragmentation_in_percent = 25.0.
> I perform the following on the index, changing the FillFactor from 90 to
> 85:
> ALTER INDEX [name of index] ON [name of database].dbo.[name of table]
> REBUILD WITH ( FILLFACTOR = 85 )
> Let's hypothetically say that it is now 7 days since this index was last
> rebuilt with a FillFactor = 85.
> Let's also hypothetically say that the same number and exact types of DML
> statements occurred on the table where this index resides during this past
> 7
> days as during the 7 day period when the index had a FillFactor = 90.
> Now let's say I query master.sys.dm_db_index_physical_stats (after 7 days
> with the FillFactor = 85) and this particular index has an
> avg_fragmentation_in_percent = 40.0.
> In optimally setting the FillFactor for this hypothetical index, from the
> above findings I would conclude that a FillFactor = 90 is a more otpimal
> setting for the index than a FillFactor = 85. Correct?
> The next step in finding the optimal FillFactor setting might be to
> increase
> the FillFactor = 95 and see how the fragmentation compares to when the
> FillFactor = 90. Correct?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200708/1
>
Optimal "set and forget" values?
Is there an optimum "set and forget" value for automatic range identity?
Set it and forget it is best when you know you are never going to add new
subscribers.
When you set it you want to use values which are going to be valid for the
lifetime of your replication solution. So for high throughput solutions, it
could be in the millions; for low throughput solutions it could be in the
10's of thousands.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Earl" <brikshoe@.newsgroups.nospam> wrote in message
news:OyRHOV8aFHA.3280@.TK2MSFTNGP09.phx.gbl...
> Is there an optimum "set and forget" value for automatic range identity?
>
|||I have a merge solution which could have as many as 50 PocketPCs (unlikely)
or as few as 5-6. Right now, I'm using an identity increment of 1 and an
identity range of 1,000,000 for both the publisher and the subscriber. The
typical subscriber would add maybe 200 records (per table) on a day, merge
changes back to the main SQL database, then delete the subscription at the
client. So I suppose that this really becomes an unlimited number of
subscribers, since a new subscription is sent down every day? I'm trying to
forecast the future here and it seems pretty murky to me. Thanks for the
advice.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:Oi9ZZn8aFHA.1148@.tk2msftngp13.phx.gbl...
> Set it and forget it is best when you know you are never going to add new
> subscribers.
> When you set it you want to use values which are going to be valid for the
> lifetime of your replication solution. So for high throughput solutions,
> it
> could be in the millions; for low throughput solutions it could be in the
> 10's of thousands.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Earl" <brikshoe@.newsgroups.nospam> wrote in message
> news:OyRHOV8aFHA.3280@.TK2MSFTNGP09.phx.gbl...
>
|||you should be good for 2,147,483,648/1,000,000 -1 (to account for the
publisher) or roughly 2,146 subscribers. If all goes well and if you expect
less than 1 million rows to be added on your publisher and each subscriber
for the lifetime of your replication solution.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Earl" <brikshoe@.newsgroups.nospam> wrote in message
news:edYmcA%23aFHA.2288@.TK2MSFTNGP14.phx.gbl...
> I have a merge solution which could have as many as 50 PocketPCs
(unlikely)
> or as few as 5-6. Right now, I'm using an identity increment of 1 and an
> identity range of 1,000,000 for both the publisher and the subscriber. The
> typical subscriber would add maybe 200 records (per table) on a day, merge
> changes back to the main SQL database, then delete the subscription at the
> client. So I suppose that this really becomes an unlimited number of
> subscribers, since a new subscription is sent down every day? I'm trying
to[vbcol=seagreen]
> forecast the future here and it seems pretty murky to me. Thanks for the
> advice.
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:Oi9ZZn8aFHA.1148@.tk2msftngp13.phx.gbl...
new[vbcol=seagreen]
the[vbcol=seagreen]
the[vbcol=seagreen]
identity?
>
|||Thanks Hilary. My expectation is for less than 1 million rows on both
publisher and subscribers. One thing that still concerns me however -- when
I delete on-board databases (subscribers) and create anew, doesn't this
indeed create a new subscriber and eat up one of my "2,146 subscribers"?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23enx9fBbFHA.3840@.tk2msftngp13.phx.gbl...
> you should be good for 2,147,483,648/1,000,000 -1 (to account for the
> publisher) or roughly 2,146 subscribers. If all goes well and if you
> expect
> less than 1 million rows to be added on your publisher and each subscriber
> for the lifetime of your replication solution.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Earl" <brikshoe@.newsgroups.nospam> wrote in message
> news:edYmcA%23aFHA.2288@.TK2MSFTNGP14.phx.gbl...
> (unlikely)
> to
> new
> the
> the
> identity?
>
|||yes, when you create a new subscriber, whether the pda had an old one before
or not, the max identity value on the publisher will be updated. This max
value is consulted when incrementing an existing range or assigning a new
one.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Earl" <brikshoe@.newsgroups.nospam> wrote in message
news:%23hY8tbHbFHA.3848@.TK2MSFTNGP10.phx.gbl...
> Thanks Hilary. My expectation is for less than 1 million rows on both
> publisher and subscribers. One thing that still concerns me however --
when[vbcol=seagreen]
> I delete on-board databases (subscribers) and create anew, doesn't this
> indeed create a new subscriber and eat up one of my "2,146 subscribers"?
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23enx9fBbFHA.3840@.tk2msftngp13.phx.gbl...
subscriber[vbcol=seagreen]
an[vbcol=seagreen]
trying[vbcol=seagreen]
the[vbcol=seagreen]
for
>
|||Very helpful Hilary. Now I just need to make a minor change to my app so as
to ensure I do not have any long-term issues with the number of subscribers.
I've estimated that -- in most scenarios -- I would've run out of identity
ranges in about a year otherwise.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23YPrULJbFHA.2380@.tk2msftngp13.phx.gbl...
> yes, when you create a new subscriber, whether the pda had an old one
> before
> or not, the max identity value on the publisher will be updated. This max
> value is consulted when incrementing an existing range or assigning a new
> one.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Earl" <brikshoe@.newsgroups.nospam> wrote in message
> news:%23hY8tbHbFHA.3848@.TK2MSFTNGP10.phx.gbl...
> when
> subscriber
> an
> trying
> the
> for
>
Set it and forget it is best when you know you are never going to add new
subscribers.
When you set it you want to use values which are going to be valid for the
lifetime of your replication solution. So for high throughput solutions, it
could be in the millions; for low throughput solutions it could be in the
10's of thousands.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Earl" <brikshoe@.newsgroups.nospam> wrote in message
news:OyRHOV8aFHA.3280@.TK2MSFTNGP09.phx.gbl...
> Is there an optimum "set and forget" value for automatic range identity?
>
|||I have a merge solution which could have as many as 50 PocketPCs (unlikely)
or as few as 5-6. Right now, I'm using an identity increment of 1 and an
identity range of 1,000,000 for both the publisher and the subscriber. The
typical subscriber would add maybe 200 records (per table) on a day, merge
changes back to the main SQL database, then delete the subscription at the
client. So I suppose that this really becomes an unlimited number of
subscribers, since a new subscription is sent down every day? I'm trying to
forecast the future here and it seems pretty murky to me. Thanks for the
advice.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:Oi9ZZn8aFHA.1148@.tk2msftngp13.phx.gbl...
> Set it and forget it is best when you know you are never going to add new
> subscribers.
> When you set it you want to use values which are going to be valid for the
> lifetime of your replication solution. So for high throughput solutions,
> it
> could be in the millions; for low throughput solutions it could be in the
> 10's of thousands.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Earl" <brikshoe@.newsgroups.nospam> wrote in message
> news:OyRHOV8aFHA.3280@.TK2MSFTNGP09.phx.gbl...
>
|||you should be good for 2,147,483,648/1,000,000 -1 (to account for the
publisher) or roughly 2,146 subscribers. If all goes well and if you expect
less than 1 million rows to be added on your publisher and each subscriber
for the lifetime of your replication solution.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Earl" <brikshoe@.newsgroups.nospam> wrote in message
news:edYmcA%23aFHA.2288@.TK2MSFTNGP14.phx.gbl...
> I have a merge solution which could have as many as 50 PocketPCs
(unlikely)
> or as few as 5-6. Right now, I'm using an identity increment of 1 and an
> identity range of 1,000,000 for both the publisher and the subscriber. The
> typical subscriber would add maybe 200 records (per table) on a day, merge
> changes back to the main SQL database, then delete the subscription at the
> client. So I suppose that this really becomes an unlimited number of
> subscribers, since a new subscription is sent down every day? I'm trying
to[vbcol=seagreen]
> forecast the future here and it seems pretty murky to me. Thanks for the
> advice.
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:Oi9ZZn8aFHA.1148@.tk2msftngp13.phx.gbl...
new[vbcol=seagreen]
the[vbcol=seagreen]
the[vbcol=seagreen]
identity?
>
|||Thanks Hilary. My expectation is for less than 1 million rows on both
publisher and subscribers. One thing that still concerns me however -- when
I delete on-board databases (subscribers) and create anew, doesn't this
indeed create a new subscriber and eat up one of my "2,146 subscribers"?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23enx9fBbFHA.3840@.tk2msftngp13.phx.gbl...
> you should be good for 2,147,483,648/1,000,000 -1 (to account for the
> publisher) or roughly 2,146 subscribers. If all goes well and if you
> expect
> less than 1 million rows to be added on your publisher and each subscriber
> for the lifetime of your replication solution.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Earl" <brikshoe@.newsgroups.nospam> wrote in message
> news:edYmcA%23aFHA.2288@.TK2MSFTNGP14.phx.gbl...
> (unlikely)
> to
> new
> the
> the
> identity?
>
|||yes, when you create a new subscriber, whether the pda had an old one before
or not, the max identity value on the publisher will be updated. This max
value is consulted when incrementing an existing range or assigning a new
one.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Earl" <brikshoe@.newsgroups.nospam> wrote in message
news:%23hY8tbHbFHA.3848@.TK2MSFTNGP10.phx.gbl...
> Thanks Hilary. My expectation is for less than 1 million rows on both
> publisher and subscribers. One thing that still concerns me however --
when[vbcol=seagreen]
> I delete on-board databases (subscribers) and create anew, doesn't this
> indeed create a new subscriber and eat up one of my "2,146 subscribers"?
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23enx9fBbFHA.3840@.tk2msftngp13.phx.gbl...
subscriber[vbcol=seagreen]
an[vbcol=seagreen]
trying[vbcol=seagreen]
the[vbcol=seagreen]
for
>
|||Very helpful Hilary. Now I just need to make a minor change to my app so as
to ensure I do not have any long-term issues with the number of subscribers.
I've estimated that -- in most scenarios -- I would've run out of identity
ranges in about a year otherwise.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23YPrULJbFHA.2380@.tk2msftngp13.phx.gbl...
> yes, when you create a new subscriber, whether the pda had an old one
> before
> or not, the max identity value on the publisher will be updated. This max
> value is consulted when incrementing an existing range or assigning a new
> one.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Earl" <brikshoe@.newsgroups.nospam> wrote in message
> news:%23hY8tbHbFHA.3848@.TK2MSFTNGP10.phx.gbl...
> when
> subscriber
> an
> trying
> the
> for
>
Monday, February 20, 2012
OPENXML INSERT/UPDATE and NTEXT
Hi,
I'm having problems inserting/updating a NTEXT field using OPENXML.
The field always gets a blank value with any parameters it receives.
Here's the (simplified) query:
---
declare @.doc int
-- Actually, it's a parameter
declare @.xml nvarchar(4000);
set @.xml = N'
<Article>
<Id>be60839f-cc33-4a9f-af91-e3bbcb7617ac</Id>
<Content>yada yada yada</Content>
</Article>'
EXEC sp_xml_preparedocument @.doc OUTPUT, @.xml
UPDATE Article
SET Content = new.Content
FROM OPENXML(@.doc, 'Article', 3) WITH Article new
WHERE Article.Id = new.Id
IF @.@.rowcount = 0
INSERT INTO Article
SELECT *
FROM OPENXML(@.doc, 'Article', 3) WITH Article
EXEC sp_xml_removedocument @.doc
---
Oddly, "SELECT * FROM OPENXML(@.doc, 'Article', 3) WITH Article" shows the
value.
Any ideas?
DiegoI think you need to revise your OPENXML syntax a bit. Try the following
instead of what you have:
UPDATE Article
SET Content = new.Content
FROM OPENXML(@.doc, 'Article', 3)
WITH (
id uniqueidentifier 'Id',
content nvarchar(400) 'Content'
) new
WHERE Article.Id = new.Id
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Diego Mijelshon" <no@.thanks.com> wrote in message
news:ei8UgeEGFHA.1188@.tk2msftngp13.phx.gbl...
> Hi,
> I'm having problems inserting/updating a NTEXT field using OPENXML.
> The field always gets a blank value with any parameters it receives.
> Here's the (simplified) query:
> ---
> declare @.doc int
> -- Actually, it's a parameter
> declare @.xml nvarchar(4000);
> set @.xml = N'
> <Article>
> <Id>be60839f-cc33-4a9f-af91-e3bbcb7617ac</Id>
> <Content>yada yada yada</Content>
> </Article>'
> EXEC sp_xml_preparedocument @.doc OUTPUT, @.xml
> UPDATE Article
> SET Content = new.Content
> FROM OPENXML(@.doc, 'Article', 3) WITH Article new
> WHERE Article.Id = new.Id
> IF @.@.rowcount = 0
> INSERT INTO Article
> SELECT *
> FROM OPENXML(@.doc, 'Article', 3) WITH Article
> EXEC sp_xml_removedocument @.doc
> ---
> Oddly, "SELECT * FROM OPENXML(@.doc, 'Article', 3) WITH Article" shows the
> value.
> Any ideas?
> Diego
>|||Adam,
Thanks for your answer, but that didn't fix it.
Besides, the beauty in the "WITH tablename" clause, combined with FOR XML
AUTO, is that I get "free" O/R-M using XML Serializing.
I'll share my solution. It still looks like a bug to me...
---
SELECT *
INTO ##tmp
FROM OPENXML(@.doc, 'Article', 3) WITH Article
UPDATE Article
SET Content = new.Content
FROM ##tmp new
WHERE Article.Id = new.Id
IF @.@.rowcount = 0
INSERT INTO Article
SELECT *
FROM ##tmp
DROP TABLE ##tmp
---
As you can see, inserting in a temporal table does the trick.
Diego
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:OxCpmzEGFHA.1476@.TK2MSFTNGP09.phx.gbl...
> I think you need to revise your OPENXML syntax a bit. Try the following
> instead of what you have:
>
> UPDATE Article
> SET Content = new.Content
> FROM OPENXML(@.doc, 'Article', 3)
> WITH (
> id uniqueidentifier 'Id',
> content nvarchar(400) 'Content'
> ) new
> WHERE Article.Id = new.Id
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
> "Diego Mijelshon" <no@.thanks.com> wrote in message
> news:ei8UgeEGFHA.1188@.tk2msftngp13.phx.gbl...
the
>|||"Diego Mijelshon" <no@.thanks.com> wrote in message
news:um$u8aIGFHA.548@.TK2MSFTNGP14.phx.gbl...
> DROP TABLE ##tmp
> ---
> As you can see, inserting in a temporal table does the trick.
I'm glad you found something that works. FYI, you should probably use a
local temporary table (single #) instead of a global one (##) unless you
need access to this same temp table from other processes...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:uWtvvjIGFHA.560@.TK2MSFTNGP15.phx.gbl...
> "Diego Mijelshon" <no@.thanks.com> wrote in message
> news:um$u8aIGFHA.548@.TK2MSFTNGP14.phx.gbl...
> I'm glad you found something that works. FYI, you should probably use a
> local temporary table (single #) instead of a global one (##) unless you
> need access to this same temp table from other processes...
Thanks for the correction, I had it backwards :-)
Diego
I'm having problems inserting/updating a NTEXT field using OPENXML.
The field always gets a blank value with any parameters it receives.
Here's the (simplified) query:
---
declare @.doc int
-- Actually, it's a parameter
declare @.xml nvarchar(4000);
set @.xml = N'
<Article>
<Id>be60839f-cc33-4a9f-af91-e3bbcb7617ac</Id>
<Content>yada yada yada</Content>
</Article>'
EXEC sp_xml_preparedocument @.doc OUTPUT, @.xml
UPDATE Article
SET Content = new.Content
FROM OPENXML(@.doc, 'Article', 3) WITH Article new
WHERE Article.Id = new.Id
IF @.@.rowcount = 0
INSERT INTO Article
SELECT *
FROM OPENXML(@.doc, 'Article', 3) WITH Article
EXEC sp_xml_removedocument @.doc
---
Oddly, "SELECT * FROM OPENXML(@.doc, 'Article', 3) WITH Article" shows the
value.
Any ideas?
DiegoI think you need to revise your OPENXML syntax a bit. Try the following
instead of what you have:
UPDATE Article
SET Content = new.Content
FROM OPENXML(@.doc, 'Article', 3)
WITH (
id uniqueidentifier 'Id',
content nvarchar(400) 'Content'
) new
WHERE Article.Id = new.Id
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Diego Mijelshon" <no@.thanks.com> wrote in message
news:ei8UgeEGFHA.1188@.tk2msftngp13.phx.gbl...
> Hi,
> I'm having problems inserting/updating a NTEXT field using OPENXML.
> The field always gets a blank value with any parameters it receives.
> Here's the (simplified) query:
> ---
> declare @.doc int
> -- Actually, it's a parameter
> declare @.xml nvarchar(4000);
> set @.xml = N'
> <Article>
> <Id>be60839f-cc33-4a9f-af91-e3bbcb7617ac</Id>
> <Content>yada yada yada</Content>
> </Article>'
> EXEC sp_xml_preparedocument @.doc OUTPUT, @.xml
> UPDATE Article
> SET Content = new.Content
> FROM OPENXML(@.doc, 'Article', 3) WITH Article new
> WHERE Article.Id = new.Id
> IF @.@.rowcount = 0
> INSERT INTO Article
> SELECT *
> FROM OPENXML(@.doc, 'Article', 3) WITH Article
> EXEC sp_xml_removedocument @.doc
> ---
> Oddly, "SELECT * FROM OPENXML(@.doc, 'Article', 3) WITH Article" shows the
> value.
> Any ideas?
> Diego
>|||Adam,
Thanks for your answer, but that didn't fix it.
Besides, the beauty in the "WITH tablename" clause, combined with FOR XML
AUTO, is that I get "free" O/R-M using XML Serializing.
I'll share my solution. It still looks like a bug to me...
---
SELECT *
INTO ##tmp
FROM OPENXML(@.doc, 'Article', 3) WITH Article
UPDATE Article
SET Content = new.Content
FROM ##tmp new
WHERE Article.Id = new.Id
IF @.@.rowcount = 0
INSERT INTO Article
SELECT *
FROM ##tmp
DROP TABLE ##tmp
---
As you can see, inserting in a temporal table does the trick.
Diego
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:OxCpmzEGFHA.1476@.TK2MSFTNGP09.phx.gbl...
> I think you need to revise your OPENXML syntax a bit. Try the following
> instead of what you have:
>
> UPDATE Article
> SET Content = new.Content
> FROM OPENXML(@.doc, 'Article', 3)
> WITH (
> id uniqueidentifier 'Id',
> content nvarchar(400) 'Content'
> ) new
> WHERE Article.Id = new.Id
>
> --
> Adam Machanic
> SQL Server MVP
> http://www.sqljunkies.com/weblog/amachanic
> --
>
> "Diego Mijelshon" <no@.thanks.com> wrote in message
> news:ei8UgeEGFHA.1188@.tk2msftngp13.phx.gbl...
the
>|||"Diego Mijelshon" <no@.thanks.com> wrote in message
news:um$u8aIGFHA.548@.TK2MSFTNGP14.phx.gbl...
> DROP TABLE ##tmp
> ---
> As you can see, inserting in a temporal table does the trick.
I'm glad you found something that works. FYI, you should probably use a
local temporary table (single #) instead of a global one (##) unless you
need access to this same temp table from other processes...
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--|||"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:uWtvvjIGFHA.560@.TK2MSFTNGP15.phx.gbl...
> "Diego Mijelshon" <no@.thanks.com> wrote in message
> news:um$u8aIGFHA.548@.TK2MSFTNGP14.phx.gbl...
> I'm glad you found something that works. FYI, you should probably use a
> local temporary table (single #) instead of a global one (##) unless you
> need access to this same temp table from other processes...
Thanks for the correction, I had it backwards :-)
Diego
Subscribe to:
Posts (Atom)