Showing posts with label books. Show all posts
Showing posts with label books. Show all posts

Wednesday, March 28, 2012

Information for Column-Level Merge Replication

Please provide me a column-level merge replication in SQL Server 2005. In the SQL Sever books online, I could able to get very few informaiton about this topic. Please provide me a best practices for using this kind of conflict resolution in Merge-replication.

Provide me a best solution for this problem

Following are my tables structure

Organization (top-level) AddressID -> ID Address

Employee (top-level) AddressID -> ID Address

Organization and employee in this scenario are isolated from each other, in terms of transactions. However, they contain linked data which lives in an Address table. In order to configure logical records in this example, the Address table would be the top-level, and the organization and employee tables would include join filters referencing it. The problem is, Organization and Employee are not really part of a logical record with Address, at least in terms of all three tables. Instead, Address and Organization participate in a logical record. Address and Employee also should be represented with a logical record.

what would be the suggested implementation approach for managing this type of relationship? I don't want to risk situations where conflicts in the employee table disallow updates to the organization table.You can try to get logical record scenario in this case.
I havent tried it myself, will do so shortly. Meanwhile go ahead and give it a try.
Make Address table the base table. Have Organization and Employee Tables join with the Address table in a Logical Record format.

Will post more after I try it out.|||Thanks for your reply. We will try to do that. Please kindly provide the solution if you achieved at your end.|||This cannot be configured with Logical records in the fashion that you desire. The address table has to be the top-level and you are bound to get conflicts in the entire logical record including organization if there was an error in employee table.
You can have logical record on one (address-employee) or the other (address-organization) but not both and address has to be the defined as the top article due to potential conflicts. This is a restriction in logical records.

Monday, March 26, 2012

Info!

Please suggest good books for SQL Server 2005
Thx MuchVai2000 wrote:
> Please suggest good books for SQL Server 2005
> Thx Much
How about the free one Microsoft provides?
http://www.microsoft.com/technet/pr...oads/books.mspx
Mike Brind|||Hi
SQL 2005 covers a vast areas and there are already many books out to cover
specific topics at different levels. You may want to look at sample chapters
from an online store to see if you like what is there. Make sure that the
book is based on the RTM version of SQL Server 2005.
John
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23IU9tklYGHA.3532@.TK2MSFTNGP05.phx.gbl...
> Please suggest good books for SQL Server 2005
> Thx Much
>

Monday, March 19, 2012

Indexing image - file size limit?

According to the Books Online information on full-text indexing, there
are limits on the size of a file that can be indexed in an image
column: 16MB filesize, 256 KB of filtered text. I've exceeded those
limits in my testing (with Word docs), and still appear to be able to
access information in those files with CONTAINS. Is the documentation
out of date? Are there only certain conditions under which those limits
apply? The word I'm searching for appears only at the end of the test
document, so it's not indexing only the first part of the file...
Since it seems to be a common question here, this is my @.@.version:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002
14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise
Edition on Windows NT 5.2 (Build 3790: )
And, just for clarity, I don't have any problem with SQL Server
indexing more than I had planned on, I just don't want any surprises
down the road.
Thanks for any ideas you have,
Joel
Last time I tested, when the hard limit was exceeded the remaining content
was not indexed.
So if you index a document containing more than 256k of text, and then put
the word rats at the end, and then tried to search on the word rats, you
would not get hits to this row, if the word rats did not occur in the first
256k of text.
One question for you is did these word docs contains any images? Images will
not be indexed, and can swell the document size, without pushing you over
the 256 k limit.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
<nospamforjoel@.yahoo.com> wrote in message
news:1105371120.743181.194610@.c13g2000cwb.googlegr oups.com...
> According to the Books Online information on full-text indexing, there
> are limits on the size of a file that can be indexed in an image
> column: 16MB filesize, 256 KB of filtered text. I've exceeded those
> limits in my testing (with Word docs), and still appear to be able to
> access information in those files with CONTAINS. Is the documentation
> out of date? Are there only certain conditions under which those limits
> apply? The word I'm searching for appears only at the end of the test
> document, so it's not indexing only the first part of the file...
> Since it seems to be a common question here, this is my @.@.version:
> Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002
> 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise
> Edition on Windows NT 5.2 (Build 3790: )
> And, just for clarity, I don't have any problem with SQL Server
> indexing more than I had planned on, I just don't want any surprises
> down the road.
> Thanks for any ideas you have,
> Joel
>
|||No, the documents that are confusing me did not have any images. They
were just a bunch of text, pasted repeatedly. I ran them through
filtdump, to make sure they really did have more than 256K of text. The
test you describe is exactly what I did--I put words at the very end of
the document that I was sure weren't in the document before, and once
the catalog rebuilt, I searched for them, and found them.
Thanks,
Joel
|||Let me try this myself. I did try this several years ago so this may have
changed with a recent sp.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
<nospamforjoel@.yahoo.com> wrote in message
news:1105386126.803682.118060@.c13g2000cwb.googlegr oups.com...
> No, the documents that are confusing me did not have any images. They
> were just a bunch of text, pasted repeatedly. I ran them through
> filtdump, to make sure they really did have more than 256K of text. The
> test you describe is exactly what I did--I put words at the very end of
> the document that I was sure weren't in the document before, and once
> the catalog rebuilt, I searched for them, and found them.
> Thanks,
> Joel
>
|||Joel,
Q. Is the documentation out of date?
A. Actually, it is wrong as there is a DOC bug filed for this limited in the
BOL title "Filtering Supported File Types" - "Note For full-text indexing,
a document must be less than 16 megabytes (MB) in size and must not contain
more than 256 kilobytes (KB) of filtered text" and this limit can be
over-ridden via KB article: 308771 (Q308771) "PRB: A Full-Text Search May
Not Return Any Hits If It Fails to Index a File" at
http://support.microsoft.com/default...;en-us;308771. and the
FilterProcessMemoryQuota registry key value. However, you should be careful
in making adjustments to this registry key and incrementally increase it
based upon your server's memory and avg. file sizes.
Q. Are there only certain conditions under which those limits apply?
A. Not specific conditions, but you should ensure that you have enough disk
free space (at least always 15% free) at all times where you have your FT
Catalog folder located as temp. files are written out as needed for the
processing of large files at the same location.
Regards,
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
<nospamforjoel@.yahoo.com> wrote in message
news:1105386126.803682.118060@.c13g2000cwb.googlegr oups.com...
> No, the documents that are confusing me did not have any images. They
> were just a bunch of text, pasted repeatedly. I ran them through
> filtdump, to make sure they really did have more than 256K of text. The
> test you describe is exactly what I did--I put words at the very end of
> the document that I was sure weren't in the document before, and once
> the catalog rebuilt, I searched for them, and found them.
> Thanks,
> Joel
>
|||I'm not entirely sure I'm clear. If I'm reading that article right, it
looks like there is still some point at which indexing a document will
fail due to lack of memory. However, that point cannot be determined by
examining the file size of the document. Is that accurate?
Thanks,
Joel
John Kane wrote:
> Joel,
> Q. Is the documentation out of date?
> A. Actually, it is wrong as there is a DOC bug filed for this limited
in the
> BOL title "Filtering Supported File Types" - "Note For full-text
indexing,
> a document must be less than 16 megabytes (MB) in size and must not
contain
> more than 256 kilobytes (KB) of filtered text" and this limit can be
> over-ridden via KB article: 308771 (Q308771) "PRB: A Full-Text Search
May
> Not Return Any Hits If It Fails to Index a File" at
> http://support.microsoft.com/default...;en-us;308771. and
the
> FilterProcessMemoryQuota registry key value. However, you should be
careful
> in making adjustments to this registry key and incrementally increase
it
> based upon your server's memory and avg. file sizes.
> Q. Are there only certain conditions under which those limits apply?
> A. Not specific conditions, but you should ensure that you have
enough disk
> free space (at least always 15% free) at all times where you have
your FT
> Catalog folder located as temp. files are written out as needed for
the[vbcol=seagreen]
> processing of large files at the same location.
> Regards,
> John
> --
> SQL Full Text Search Blog
> http://spaces.msn.com/members/jtkane/
>
> <nospamforjoel@.yahoo.com> wrote in message
> news:1105386126.803682.118060@.c13g2000cwb.googlegr oups.com...
They[vbcol=seagreen]
The[vbcol=seagreen]
end of[vbcol=seagreen]
once[vbcol=seagreen]
|||You're welcome, Joel,
Yea, the RESOLUTION section states "Unfortunately, there is no way to
calculate directly from the size of the document to be full-text indexed how
much memory the filter process needs. The memory quota only exists to
protect against badly written filters, and they do spike to large amounts if
some bogus size contains a negative number. The quota itself can be made
larger, as long as it is finite. "
While no upper limit size for documents to be FT Indexed is documented, you
can increase the amount of text to be indexed by modifying the
FilterProcessMemoryQuota registry key value and you need to test your
documents on your server to get a feel for what is the "finite" limit and
monitor the server's application event log for "Microsoft Search" source
events for very large files that fail.
Regards,
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
<nospamforjoel@.yahoo.com> wrote in message
news:1105452953.633306.318410@.f14g2000cwb.googlegr oups.com...
> I'm not entirely sure I'm clear. If I'm reading that article right, it
> looks like there is still some point at which indexing a document will
> fail due to lack of memory. However, that point cannot be determined by
> examining the file size of the document. Is that accurate?
> Thanks,
> Joel
> John Kane wrote:
> in the
> indexing,
> contain
> May
> the
> careful
> it
> enough disk
> your FT
> the
> They
> The
> end of
> once
>
|||I just tried it again. I indexed a 32 Mg text and a 16 Mg word doc and have
confirmed that at least first 256 k of extracted text is indexed, but that
tokens at the end of the documents are not. Any textual data after this 256k
boundary appears to be ignored.
I have the same version of SQL Server as you, only I am running on Win2k.
Let me try with Win2003.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:u6I6P509EHA.3376@.TK2MSFTNGP12.phx.gbl...
> Let me try this myself. I did try this several years ago so this may have
> changed with a recent sp.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> <nospamforjoel@.yahoo.com> wrote in message
> news:1105386126.803682.118060@.c13g2000cwb.googlegr oups.com...
>

Sunday, February 19, 2012

Indexed Views Vs temp tables

With my understanding of indexed views and according to books I read
"indexed views" are supposed to perform much better than "temp tables"
(temp table having primary key and indexed view with clustered index
on the same keys).

But when I tried in my system I am getting opposite results. With
Indexed Views it takes 3 times more time.

Any body has any reasons for that? Or my understanding was wrong?

thanks
Raghu AvirneniIndexed views are expensive when adding data, since adding to the base table
also has to update the view's indexes as well as the base table.

It only helps on the retrieve (and only if the index on the view is used in
the query plan).

I have only used them for lookup tables that rarely change.

"Avirneni" <ravirneni@.trafficmp.com> wrote in message
news:15a48475.0410061606.24dd220d@.posting.google.c om...
> With my understanding of indexed views and according to books I read
> "indexed views" are supposed to perform much better than "temp tables"
> (temp table having primary key and indexed view with clustered index
> on the same keys).
> But when I tried in my system I am getting opposite results. With
> Indexed Views it takes 3 times more time.
> Any body has any reasons for that? Or my understanding was wrong?
>
> thanks
> Raghu Avirneni|||Temp tables and views are different animals. Like David mentioned, examine
the query plan to ensure the index on the view is actually being used.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Avirneni" <ravirneni@.trafficmp.com> wrote in message
news:15a48475.0410061606.24dd220d@.posting.google.c om...
> With my understanding of indexed views and according to books I read
> "indexed views" are supposed to perform much better than "temp tables"
> (temp table having primary key and indexed view with clustered index
> on the same keys).
> But when I tried in my system I am getting opposite results. With
> Indexed Views it takes 3 times more time.
> Any body has any reasons for that? Or my understanding was wrong?
>
> thanks
> Raghu Avirneni