Hello, I have situation as followed. Do you think merge replication would
be able to keep both databases in sync?
We have two databases (a primary and a secondary)
Regular users use the primary database. To keep the secondary data in sync
with the primary, I have a job running everyday to copy and replace the
tables
and data in the secondary database.
Assuming the primary database is offline and users use the secondary. And
users update/add to the secondary database. Now, the primary database is
back on line. How should I plan to sync the secondary database data
with the primary? Can it be done by merge replication? Can merge
replication
be setup so if there is update in the primary, the secondary will be update.
And when there is update in the secondary, the primary will be updated?
What to setup so both copies of the database have the same data if
I want them to have the same data all the time?
Thanks,
Q
Q,
there was a thread on this last week answered by me, Hilary and Mike Hotek
called 'add a field'. This is a big topic and there are many angles. You
might consider:
transactional replication with queued updating subscribers,
database mirroring and
merge replication.
Each has its pros and cons - largely covered in the thread mentioned above.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||You can add transactional with immediate updating, bi-directional
transactional, and peer-to-peer transactional since this question is a more
general case and doesn't specify versions or editions.
200 - 300 pages later, you would still wind up with the answer of it
depends. All of them will work, but it depends upon lots of things in your
environment to be able to decide one way or the other.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23uWY0KUGGHA.3984@.TK2MSFTNGP14.phx.gbl...
> Q,
> there was a thread on this last week answered by me, Hilary and Mike Hotek
> called 'add a field'. This is a big topic and there are many angles. You
> might consider:
> transactional replication with queued updating subscribers,
> database mirroring and
> merge replication.
> Each has its pros and cons - largely covered in the thread mentioned
> above.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Mike,
I would not include transactional with immediate updating in this mix. If
the primary server is down, the poster wants to be able to use the secondary
one, and the inability to do a 2PC will prevent any changes being made on
the subscriber in this case.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Further note that bi directional replication is not really scalable due to
no conflict mechanism; peer-to-peer is not scalable beyond 12-15 nodes.
Updateable subscription types are best when the majority of DML occurs on
the publisher. Updateable Subscriptions allow conflicts to be logged but not
rolled back.
Merge replication is scalable to 1,000 or subscribers, it has a rich
conflict detection and resolution mechanism, and there is no restriction
with where the majority of DML occurs.
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
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:u%23sNLR0GGHA.1192@.TK2MSFTNGP11.phx.gbl...
> Mike,
> I would not include transactional with immediate updating in this mix. If
> the primary server is down, the poster wants to be able to use the
> secondary one, and the inability to do a 2PC will prevent any changes
> being made on the subscriber in this case.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||That's really baffling. Those are some pretty absolute numbers being thrown
around. How does conflict detection have anything at all to do with
scalability?
If I want to, I can build a bi-directional transactional configuration in a
linear chain that has 1000 servers in it and make it work perfectly fine, so
that blows your "can't scale" theory out of the water, because it can in
fact be done. (Although I don't have an explicit business application for
that.)
How do you figure that peer-to-peer is not scalable beyond 12 - 15 nodes?
Just what exactly was your test platform that gave you those explicit
numbers. I'd really like to know, because my testing has taken it out to 30
nodes and everything was still working.
I've done updating subscribers in configurations where not only where there
dozens of subscribers, but over 90% of the changes occured on the
subscribers.
There is no such thing as rolling back from a conflict. A rollback occurs
within a transaction space and causes changes to be undone before they are
committed to the database. A conflict is thrown against committed and
completely valid data in the database. The only thing that conflict
resolution can do is produce a compensating transaction which is then
applied, but it is still a completely separate transaction that modifies
data. (It most certainly doesn't rollback.)
Merge is scalable to 1000 subscribers? Really. How do you figure? I've
had a merge architecture in place and running perfectly fine since SQL
Server 7.0 that had over 10,000 subscribers in the architecture. I've also
had merge architectures which couldn't scale beyond 5 subscribers.
I really like these nice blanket statements being thrown out. Particularly
since they have zero basis in reality. The reality of replication is that
scalability has a direct correspondence to the volume of data per unit time
that is being sent through the engine. It has ZERO correspondence to the
number of subscribers or the pattern of modifications. When you say "does
not scale beyond x", that means it plain and simply does not work if you try
it. That is obviously a completely false statement, because you can ALWAYS
get something to scale beyond x.
Keep in mind there are a LOT of people out here reading this. When you say
that a technology can't scale beyond X, then people are going to start
looking for different tecnologies to apply, because according to you, the
replication engine can't meet their business requirements. It also makes it
really difficult for SQL Server DBAs to architect systems, because their
managers point to your posts which say that SQL Server can't do what they
are proposing to do and no amount of testing is going to change their minds
once they've decided. So, how about giving the people who wrote the code
for the replication engine a break and if you are going to post a
scalability number, back it up with enough information to explicitly define
the entire environment that drew that conclusion.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eqHw513GGHA.1388@.TK2MSFTNGP11.phx.gbl...
> Further note that bi directional replication is not really scalable due to
> no conflict mechanism; peer-to-peer is not scalable beyond 12-15 nodes.
> Updateable subscription types are best when the majority of DML occurs on
> the publisher. Updateable Subscriptions allow conflicts to be logged but
> not rolled back.
> Merge replication is scalable to 1,000 or subscribers, it has a rich
> conflict detection and resolution mechanism, and there is no restriction
> with where the majority of DML occurs.
> --
> 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
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:u%23sNLR0GGHA.1192@.TK2MSFTNGP11.phx.gbl...
>
|||Most of my figures come from a recent presenation that Phil Vaughn did at
Pass this year on replication. I'll listen to it again and verify these
numbers. If I am incorrect I will post back here with the corrections. I'll
also ping him to verify these quotes. Paul Ibison has a copy of the same
presentation.
While I have no doubt that you have built such systems let me quote from BOL
In a section entitled Queued Updating - Queued updating is most appropriate
for applications where users mostly read data and only occasionally update
data.
In a section entitled Immediate Updating - . Immediate updating benefits
applications in which snapshot or transactional publications are preferred
but occasional updates need to be made at the Subscriber.
While BOL has occasionally being inaccurate, it is my belief and experience
that it is completely correct here.
When I say something is rolled back, I mean it in the same sense a
transaction is rolled back and the system is left in the state is was in
before. You can use the conflict viewer to "rollback" replication changes,
or as they put it "keep the Wining Change", resubmit delete, insert, update.
Note that in SQL 2000 you have an option to compensate for errors which had
a default of false. In SQL 2005 it has a default of true. In other words
conflicts will be logged but the changes will not win on the subscriber with
this setting as false.
As I have stated previously in this newsgroup Paul and I have a committment
to accuracy and helping people with correct information. I trust you have
the same committment.
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
"Michael Hotek" <mike@.solidqualitylearning.com> wrote in message
news:OFKLzQ6GGHA.2696@.TK2MSFTNGP14.phx.gbl...
> That's really baffling. Those are some pretty absolute numbers being
> thrown around. How does conflict detection have anything at all to do
> with scalability?
> If I want to, I can build a bi-directional transactional configuration in
> a linear chain that has 1000 servers in it and make it work perfectly
> fine, so that blows your "can't scale" theory out of the water, because it
> can in fact be done. (Although I don't have an explicit business
> application for that.)
> How do you figure that peer-to-peer is not scalable beyond 12 - 15 nodes?
> Just what exactly was your test platform that gave you those explicit
> numbers. I'd really like to know, because my testing has taken it out to
> 30 nodes and everything was still working.
> I've done updating subscribers in configurations where not only where
> there dozens of subscribers, but over 90% of the changes occured on the
> subscribers.
> There is no such thing as rolling back from a conflict. A rollback occurs
> within a transaction space and causes changes to be undone before they are
> committed to the database. A conflict is thrown against committed and
> completely valid data in the database. The only thing that conflict
> resolution can do is produce a compensating transaction which is then
> applied, but it is still a completely separate transaction that modifies
> data. (It most certainly doesn't rollback.)
> Merge is scalable to 1000 subscribers? Really. How do you figure? I've
> had a merge architecture in place and running perfectly fine since SQL
> Server 7.0 that had over 10,000 subscribers in the architecture. I've
> also had merge architectures which couldn't scale beyond 5 subscribers.
> I really like these nice blanket statements being thrown out.
> Particularly since they have zero basis in reality. The reality of
> replication is that scalability has a direct correspondence to the volume
> of data per unit time that is being sent through the engine. It has ZERO
> correspondence to the number of subscribers or the pattern of
> modifications. When you say "does not scale beyond x", that means it
> plain and simply does not work if you try it. That is obviously a
> completely false statement, because you can ALWAYS get something to scale
> beyond x.
> Keep in mind there are a LOT of people out here reading this. When you
> say that a technology can't scale beyond X, then people are going to start
> looking for different tecnologies to apply, because according to you, the
> replication engine can't meet their business requirements. It also makes
> it really difficult for SQL Server DBAs to architect systems, because
> their managers point to your posts which say that SQL Server can't do what
> they are proposing to do and no amount of testing is going to change their
> minds once they've decided. So, how about giving the people who wrote the
> code for the replication engine a break and if you are going to post a
> scalability number, back it up with enough information to explicitly
> define the entire environment that drew that conclusion.
> --
> Mike
> http://www.solidqualitylearning.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:eqHw513GGHA.1388@.TK2MSFTNGP11.phx.gbl...
>
|||The presentation is #336 - SQL Server 2005 Replication: Lesson's learned
from Early Adopters, in a slide entitled Peer to Peer Topology, in response
to an inaudible question, Phil has this to say "Realistically speaking when
once you get to about 10-12, you start sending around so many changes you
get to a point of diminishing returns, but about 10-12 nodes is where it
peaks out, cause all changes flow everywhere."
The transcription is mine. You can order this cd from the pass website. I
suggest you follow up with Phil if you have more questions about his remarks
or figures. If you are able to make this scale out to 30 servers I am sure
Microsoft would be very interested in speaking with you.
Phil also says (another quote from the same slide) in reference to
bi-directional transactional replication - "it supported one node, and two
nodes, but you couldn't extend it beyond 2."
If you want to contact me I can play these sound clips for you. I can
contact Kevin Kline president of Pass and ask him for permission to publish
the audio's for these slides if you require it, but I urge you to contact
Phil or to follow up with your Microsoft contacts.
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
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uIq8356GGHA.3100@.tk2msftngp13.phx.gbl...
> Most of my figures come from a recent presenation that Phil Vaughn did at
> Pass this year on replication. I'll listen to it again and verify these
> numbers. If I am incorrect I will post back here with the corrections.
> I'll also ping him to verify these quotes. Paul Ibison has a copy of the
> same presentation.
> While I have no doubt that you have built such systems let me quote from
> BOL
> In a section entitled Queued Updating - Queued updating is most
> appropriate for applications where users mostly read data and only
> occasionally update data.
> In a section entitled Immediate Updating - . Immediate updating benefits
> applications in which snapshot or transactional publications are preferred
> but occasional updates need to be made at the Subscriber.
> While BOL has occasionally being inaccurate, it is my belief and
> experience that it is completely correct here.
> When I say something is rolled back, I mean it in the same sense a
> transaction is rolled back and the system is left in the state is was in
> before. You can use the conflict viewer to "rollback" replication changes,
> or as they put it "keep the Wining Change", resubmit delete, insert,
> update.
> Note that in SQL 2000 you have an option to compensate for errors which
> had a default of false. In SQL 2005 it has a default of true. In other
> words conflicts will be logged but the changes will not win on the
> subscriber with this setting as false.
> As I have stated previously in this newsgroup Paul and I have a
> committment to accuracy and helping people with correct information. I
> trust you have the same committment.
> --
> 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
> "Michael Hotek" <mike@.solidqualitylearning.com> wrote in message
> news:OFKLzQ6GGHA.2696@.TK2MSFTNGP14.phx.gbl...
>
|||Thanks, you don't have to. I don't need the slides. I know exactly what is
being said. It also isn't an absolute statement. When you say "doesn't
scale" or something else to that effect, to me it means it physically can
NOT be done as in the engine blows up, throws error messages, prevents you
from doing it etc.
While BOL may say that it was designed for a particular application, that
doesn't mean it can't be used for something else. The merge engine
certainly wasn't designed for 500GB+ databases when it released in 7.0, but
it was certainly done. The queued updating option had an original design
spec for scenarios where most of the updates happened at the subscriber, but
more than 90% of the implementations I've put in (numbering in the over 100
implementations category) had nearly 100% of the changes occuring at the
subscriber. So, there are hundreds of cases that I've personally done which
disagree significantly with BOL. I also have several queued updating
architectures with more than 50 subscribers which again disagrees with your
absolute numbers.
As far as peer-to-peer goes, it really depends upon what you are doing and
what you are running on. On a quad processor Xeon, I had a hard time
getting 6 of them running where I had 100 or so changes per minute going in
the system. If I chopped that down to 50 changes per minute, I could double
the number of subscribers before it started slowing down. If I changed from
Windows 2000 to Windows 2003, I could add a couple more. If I moved it to a
quad, dual core, Opteron, I shoved it for 30 in a peer-to-peer architecture
with about 50 changes per minute going on before it started to bog down. If
I increased it to 200 per minute, I had to chop out ~1/4 of the subscribers.
If I moved from issuing the transactions against a 30 column table to doing
it against a 5 column table, I could shove it up to about 400 changes per
minute before it started to bog down. So, the number are VERY HIGHLY
DEPENDENT upon precisely what you are doing.
If you are going to post numbers, particularly with the replication engine,
I am ALWAYS going to dispute them. (Plain and simply because since way back
in SQL Server 6.5, I've had implementations in production that have ALWAYS
exceeded any type of numbers Microsoft has posted and have ALWAYS had
implementations doing things that a feature wasn't originally designed to
do.) You had better be prepared to explicitly specify:
1. OS version
2. OS configuration
3. Hardware config
4. SQL Server version
5. SQL Server config
6. Network infrastructure
7. Network bandwidth statistics
8. Database structure
9. Write activity
a. Volume broken down by inserts, updates, and deletes
b. Broken down by transaction per minute
c. Broken down by transaction pattern
10. Replication method
11. Replication config
If you aren't meeting at least those set of requirements, any numbers that
are posted are VERY BASIC rules of thumb at the very least and most
definitely do not impose limitations or prevent you from surpassing them.
They most definitely are not meant to be thrown around as absolute barriers
to doing something. If the interest is in being accurate, then any time
numbers are posted, they certainly should not be posted in these 1 and 2
sentence blurbs that convey the meaning that if you are looking to exceed
those numbers, you had better look at some other technology because the
replication engine can't do X.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eZe%23ZE%23GGHA.3752@.TK2MSFTNGP11.phx.gbl...
> The presentation is #336 - SQL Server 2005 Replication: Lesson's learned
> from Early Adopters, in a slide entitled Peer to Peer Topology, in
> response to an inaudible question, Phil has this to say "Realistically
> speaking when once you get to about 10-12, you start sending around so
> many changes you get to a point of diminishing returns, but about 10-12
> nodes is where it peaks out, cause all changes flow everywhere."
> The transcription is mine. You can order this cd from the pass website. I
> suggest you follow up with Phil if you have more questions about his
> remarks or figures. If you are able to make this scale out to 30 servers I
> am sure Microsoft would be very interested in speaking with you.
> Phil also says (another quote from the same slide) in reference to
> bi-directional transactional replication - "it supported one node, and two
> nodes, but you couldn't extend it beyond 2."
> If you want to contact me I can play these sound clips for you. I can
> contact Kevin Kline president of Pass and ask him for permission to
> publish the audio's for these slides if you require it, but I urge you to
> contact Phil or to follow up with your Microsoft contacts.
> --
> 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
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uIq8356GGHA.3100@.tk2msftngp13.phx.gbl...
>
Showing posts with label situation. Show all posts
Showing posts with label situation. Show all posts
Sunday, March 11, 2012
Friday, February 24, 2012
can I use * to specify 'Output Column' for OLD DB Source Editor?
I am working on a situation similar to 'Get all from Table A that isn't in Table B' http://www.sqlis.com/default.aspx?311
I noticed that if one column's name of source table changes,(say Year to Year2) I have to modify all 'data flow transformations' in the task.
I am new to SSIS.
thanks! -ZZ
ZZhang wrote:
I am working on a situation similar to 'Get all from Table A that isn't in Table B' http://www.sqlis.com/default.aspx?311
I noticed that if one column's name of source table changes,(say Year to Year2) I have to modify all 'data flow transformations' in the task.
I am new to SSIS.
thanks! -ZZ
You could use '*' if you wanted but this is about as bad as bad practice gets. Don't do it. If the name of a column changes then SSIS will break because it stored the metadata of the external data source. This is by design.
-Jamie
|||
Hi, Jamie,
Thanks so much for your quick response! I have two questions then.
1. How to use * ? I can not find it in the 'OLD DB Source Editor'.
2. Let me simplifing my case. I have a remote source table ( which has may columns, incluing 'ID' and 'Date'). The schema may change, but not 'ID' and 'Date' columns. The DTS job is to get all rows ( select * from myTable where [Date] = getdate() ), and output to a delimited flat file.
What is the best practice SSIS for this case?
Thanks again!
-ZZ
|||Like I said. You can't do it. If the external metadata changes then your data-flow will error.
-Jamie
|||
thanks, Jamie!
Honestly, this surprised me, if it can not use *. I will choose NOT to use SSIS for my simple job, because it does not make sense to modify ( and test) SSIS package every time the schema changes. I hope there is a workaround to meet my job requirement in SSIS.
-ZZ
|||What? Your problem is the fact that your schema is changing, not that SSIS can't handle it. Are you saying that its impossible to know what your schema will look like from one day to the next? I've never seen a company that would run its systems like that nor would i want to.
Sorry to sound rude but it just sounds crazy to me!
-Jamie
|||
Thanks Jamie for your time to answer my question!
I am new to SSIS, and have not used variable, expression, and sricpt much. I am open-mind, and believe there is a way (simple or difficult), to solve my issue. Maybe you are right, but here I am searching 'how-to' solution, like ( select * from MyTable). Should I use *? it is another question.
Thanks again!
-ZZhang
|||Again,
Yes you can use "SELECT * FROM MyTable"|||
It seems that MS has solution for 'Dynamic Metadata', although SSIS pipeline requires static metadata.
"Advacned ETL: Embedding Integration Services" from PDC05 mentioned this issue. SMO is needed.
I am still searching for the samples.
-ZZhang
can I use * to specify 'Output Column' for OLD DB Source Editor?
I am working on a situation similar to 'Get all from Table A that isn't in Table B' http://www.sqlis.com/default.aspx?311
I noticed that if one column's name of source table changes,(say Year to Year2) I have to modify all 'data flow transformations' in the task.
I am new to SSIS.
thanks! -ZZ
I am working on a situation similar to 'Get all from Table A that isn't in Table B' http://www.sqlis.com/default.aspx?311
I noticed that if one column's name of source table changes,(say Year to Year2) I have to modify all 'data flow transformations' in the task.
I am new to SSIS.
thanks! -ZZ
You could use '*' if you wanted but this is about as bad as bad practice gets. Don't do it. If the name of a column changes then SSIS will break because it stored the metadata of the external data source. This is by design.
-Jamie
|||
Hi, Jamie,
Thanks so much for your quick response! I have two questions then.
1. How to use * ? I can not find it in the 'OLD DB Source Editor'.
2. Let me simplifing my case. I have a remote source table ( which has may columns, incluing 'ID' and 'Date'). The schema may change, but not 'ID' and 'Date' columns. The DTS job is to get all rows ( select * from myTable where [Date] = getdate() ), and output to a delimited flat file.
What is the best practice SSIS for this case?
Thanks again!
-ZZ
|||Like I said. You can't do it. If the external metadata changes then your data-flow will error.
-Jamie
|||
thanks, Jamie!
Honestly, this surprised me, if it can not use *. I will choose NOT to use SSIS for my simple job, because it does not make sense to modify ( and test) SSIS package every time the schema changes. I hope there is a workaround to meet my job requirement in SSIS.
-ZZ
|||What? Your problem is the fact that your schema is changing, not that SSIS can't handle it. Are you saying that its impossible to know what your schema will look like from one day to the next? I've never seen a company that would run its systems like that nor would i want to.
Sorry to sound rude but it just sounds crazy to me!
-Jamie
|||
Thanks Jamie for your time to answer my question!
I am new to SSIS, and have not used variable, expression, and sricpt much. I am open-mind, and believe there is a way (simple or difficult), to solve my issue. Maybe you are right, but here I am searching 'how-to' solution, like ( select * from MyTable). Should I use *? it is another question.
Thanks again!
-ZZhang
|||Again,
Yes you can use "SELECT * FROM MyTable"|||
It seems that MS has solution for 'Dynamic Metadata', although SSIS pipeline requires static metadata.
"Advacned ETL: Embedding Integration Services" from PDC05 mentioned this issue. SMO is needed.
I am still searching for the samples.
-ZZhang
Can I Turn off Auto Execution of Report when all parameters have default values?
My situation....
I deploy a report in Report Server. Ther report has 5-10 parameters. When I design the report, I supply a default value for each parameter, similiar to the "Add a select all option" tutorials.
So I end up with defaults like "Select a Project Manager", "Select a Fiscal Year", etc... I use dynamic queries to read the parameters and insert the appropriate logic into the where string of my main dataset. If the user selects a value from my parameter lists, I append a clause to the SQL string, if they choose the default option, I ignore the parameter, and that effectively returns all of the records (like Select * from ....)
My Issue...
When I provide a default paramater for ALL of the parameters available, the report auto-executes when the user picks it from the folder, and isn;t given the opportunity to refine the default criteria I have provided.
My Question....
Is there any way to turn the autoexecution off?
Thanks for any help...
There is no method to turn off the auto execution of the report if all parameters have default values.
As you have probable already found out, you can populate all but one of the parameters to get the result you desire. But that makes the user have to supply a value of the parameter.
Can I trust Microsoft for FOR XML AUTO or FOR XML RAW ?
Hi,
I have been there a situation of an apprehension that Microsoft may issue
some patch or hotfix in future for SQL SERVER, that will change the shape of
XML results yielded by FOR XML AUTO or FOR XML RAW query.
Our query is going to be rigid in the application and the data would then be
passed through sensitive application that may crash if xml is not valid, we
have many types of xmls so we cannot create schema for each and every guy an
d
same with EXPLICIT.
Is this superstition valid that I shouldnt trust Microsoft here ?
Any input in this will sincerely be appreciated.
Fahad"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
FOR XML AUTO and FOR XML RAW results are pretty well defined, since SQL
2000. It's doubtful these would change in the current version of SQL Server
(2005) or espcially in 2000. A lot of people have already written
applications that use this functionality which would surely break if they
changed it. However the results are subject to change if your schema
changes which is probably a much more likely situation.
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
I would recommend using FOR XML PATH if you have SQL 2005. It's easy to
use, uses XPath notation to define your XML, and you can easily update or
modify it if your schema changes.
> Is this superstition valid that I shouldnt trust Microsoft here ?
Like I said, if they change this in a Service Pack (and it's been around
since SQL 2000), they are going to have a lot of unhappy customers who have
invested a lot of time and money in building applications to use it. OTOH,
one could say the same thing about COM and VB 6 :) At any rate I wouldn't
worry too much about it until at least the next major version release.|||"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
I know Microsoft occasionally make breaking changes but normally they go the
other way, everything has to be backwards compatible even to the detriment
of the latest version.
Have you any specific reason for worrying that the FOR XML statements are
going to be modified?
Joe Fawcett (MVP - XML)
http://joe.fawcett.name|||This seems like a strange thing to worry about. Aside from the basic issue
of how else would you represent a simple result set as XML, what motivation
would there be to ever changing this? What would happen if Microsoft did
this? There would be thousands of blog entries, newsgroup postings, and
news articles vilifying Microsoft for sticking it to the little guy, the
stock would drop, hundreds of employees would have to change their
retirement plans, and the SQL team would be hated by the rest of Microsoft.
Contrast this with the alternative of not changing code that works well
already and it makes changing the format a poor alternative.
Reading between the lines of your post makes me worry that you plan to do
some kind of roll your own text parsing instead of using a real XML parser.
If this is true then there could be an issue. While the results will be
semantically the same, it's hard to guarantee character for character
compatibility forever. If you want to do your own parsing you are better
off using something like comma separated values.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Reading between the lines of your post makes me worry that you plan to do
> some kind of roll your own text parsing instead of using a real XML
> parser. If this is true then there could be an issue. While the results
> will be semantically the same, it's hard to guarantee character for
> character compatibility forever. If you want to do your own parsing you
> are better off using something like comma separated values.
Do you see this being a problem if the OP is using Unicode?|||Could you expand a bit on what you mean? I'm not sure how Unicode fits into
the question.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:%238jjscTSHHA.5060@.TK2MSFTNGP06.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Do you see this being a problem if the OP is using Unicode?
>|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> Could you expand a bit on what you mean? I'm not sure how Unicode fits
> into the question.
"While the results will be semantically the same, it's hard to guarantee
character for character compatibility forever."
I assumed you were talking about character sets, code pages, etc., in your
"character for character compatibility" statement. Did I misunderstand?|||No, I was talking about white space and namespace prefixes, etc. These are
the things that break when people write their own parsers instead of using a
full XML parser.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:uvLHAwWSHHA.3948@.TK2MSFTNGP05.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> "While the results will be semantically the same, it's hard to guarantee
> character for character compatibility forever."
> I assumed you were talking about character sets, code pages, etc., in your
> "character for character compatibility" statement. Did I misunderstand?
>|||As the program manager still responsible for FOR XML, we are not planning on
changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unless
we guard it by a backwards-compatibility flag and will document the changed
behaviour ahead of time).
Between SQL Server 2000 and 2005 we did a few changes, mostly along the
lines of entitization changes. We had one breaking change in how FOR XML
AUTO dealt with subqueries and views that caused some pain, but was actually
a bug fix in the design of FOR XML AUTO's heuristics.
So if you can be more specific of what changes you fear, I can give you a
more definitive answer.
Changes that may happen in the future include addition or removal or certain
namespace declarations, changing order of attributes. But we are not
planning on changing the resultshapes of the different modes.
Best regards
Michael
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>|||Thankyou very much for your interest in helping me Michael and other guys to
o.
Well I am getting simple shaped XML from a single table which we then
transform using XSL. The changes which I am anticipating include
Adding any namespace to data element that will make our XPath expressions
useless. We will NEVER be able to update XPaths and issue new release of our
software once it is burnt into the hardware.
Changes in the source tree, again it will require us to update XSL.
"Michael Rys [MSFT]" wrote:
> As the program manager still responsible for FOR XML, we are not planning
on
> changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unles
s
> we guard it by a backwards-compatibility flag and will document the change
d
> behaviour ahead of time).
> Between SQL Server 2000 and 2005 we did a few changes, mostly along the
> lines of entitization changes. We had one breaking change in how FOR XML
> AUTO dealt with subqueries and views that caused some pain, but was actual
ly
> a bug fix in the design of FOR XML AUTO's heuristics.
> So if you can be more specific of what changes you fear, I can give you a
> more definitive answer.
> Changes that may happen in the future include addition or removal or certa
in
> namespace declarations, changing order of attributes. But we are not
> planning on changing the resultshapes of the different modes.
> Best regards
> Michael
> "Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in messag
e
> news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
>
>
I have been there a situation of an apprehension that Microsoft may issue
some patch or hotfix in future for SQL SERVER, that will change the shape of
XML results yielded by FOR XML AUTO or FOR XML RAW query.
Our query is going to be rigid in the application and the data would then be
passed through sensitive application that may crash if xml is not valid, we
have many types of xmls so we cannot create schema for each and every guy an
d
same with EXPLICIT.
Is this superstition valid that I shouldnt trust Microsoft here ?
Any input in this will sincerely be appreciated.
Fahad"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
FOR XML AUTO and FOR XML RAW results are pretty well defined, since SQL
2000. It's doubtful these would change in the current version of SQL Server
(2005) or espcially in 2000. A lot of people have already written
applications that use this functionality which would surely break if they
changed it. However the results are subject to change if your schema
changes which is probably a much more likely situation.
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
I would recommend using FOR XML PATH if you have SQL 2005. It's easy to
use, uses XPath notation to define your XML, and you can easily update or
modify it if your schema changes.
> Is this superstition valid that I shouldnt trust Microsoft here ?
Like I said, if they change this in a Service Pack (and it's been around
since SQL 2000), they are going to have a lot of unhappy customers who have
invested a lot of time and money in building applications to use it. OTOH,
one could say the same thing about COM and VB 6 :) At any rate I wouldn't
worry too much about it until at least the next major version release.|||"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
I know Microsoft occasionally make breaking changes but normally they go the
other way, everything has to be backwards compatible even to the detriment
of the latest version.
Have you any specific reason for worrying that the FOR XML statements are
going to be modified?
Joe Fawcett (MVP - XML)
http://joe.fawcett.name|||This seems like a strange thing to worry about. Aside from the basic issue
of how else would you represent a simple result set as XML, what motivation
would there be to ever changing this? What would happen if Microsoft did
this? There would be thousands of blog entries, newsgroup postings, and
news articles vilifying Microsoft for sticking it to the little guy, the
stock would drop, hundreds of employees would have to change their
retirement plans, and the SQL team would be hated by the rest of Microsoft.
Contrast this with the alternative of not changing code that works well
already and it makes changing the format a poor alternative.
Reading between the lines of your post makes me worry that you plan to do
some kind of roll your own text parsing instead of using a real XML parser.
If this is true then there could be an issue. While the results will be
semantically the same, it's hard to guarantee character for character
compatibility forever. If you want to do your own parsing you are better
off using something like comma separated values.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Reading between the lines of your post makes me worry that you plan to do
> some kind of roll your own text parsing instead of using a real XML
> parser. If this is true then there could be an issue. While the results
> will be semantically the same, it's hard to guarantee character for
> character compatibility forever. If you want to do your own parsing you
> are better off using something like comma separated values.
Do you see this being a problem if the OP is using Unicode?|||Could you expand a bit on what you mean? I'm not sure how Unicode fits into
the question.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:%238jjscTSHHA.5060@.TK2MSFTNGP06.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Do you see this being a problem if the OP is using Unicode?
>|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> Could you expand a bit on what you mean? I'm not sure how Unicode fits
> into the question.
"While the results will be semantically the same, it's hard to guarantee
character for character compatibility forever."
I assumed you were talking about character sets, code pages, etc., in your
"character for character compatibility" statement. Did I misunderstand?|||No, I was talking about white space and namespace prefixes, etc. These are
the things that break when people write their own parsers instead of using a
full XML parser.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:uvLHAwWSHHA.3948@.TK2MSFTNGP05.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> "While the results will be semantically the same, it's hard to guarantee
> character for character compatibility forever."
> I assumed you were talking about character sets, code pages, etc., in your
> "character for character compatibility" statement. Did I misunderstand?
>|||As the program manager still responsible for FOR XML, we are not planning on
changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unless
we guard it by a backwards-compatibility flag and will document the changed
behaviour ahead of time).
Between SQL Server 2000 and 2005 we did a few changes, mostly along the
lines of entitization changes. We had one breaking change in how FOR XML
AUTO dealt with subqueries and views that caused some pain, but was actually
a bug fix in the design of FOR XML AUTO's heuristics.
So if you can be more specific of what changes you fear, I can give you a
more definitive answer.
Changes that may happen in the future include addition or removal or certain
namespace declarations, changing order of attributes. But we are not
planning on changing the resultshapes of the different modes.
Best regards
Michael
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>|||Thankyou very much for your interest in helping me Michael and other guys to
o.
Well I am getting simple shaped XML from a single table which we then
transform using XSL. The changes which I am anticipating include
Adding any namespace to data element that will make our XPath expressions
useless. We will NEVER be able to update XPaths and issue new release of our
software once it is burnt into the hardware.
Changes in the source tree, again it will require us to update XSL.
"Michael Rys [MSFT]" wrote:
> As the program manager still responsible for FOR XML, we are not planning
on
> changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unles
s
> we guard it by a backwards-compatibility flag and will document the change
d
> behaviour ahead of time).
> Between SQL Server 2000 and 2005 we did a few changes, mostly along the
> lines of entitization changes. We had one breaking change in how FOR XML
> AUTO dealt with subqueries and views that caused some pain, but was actual
ly
> a bug fix in the design of FOR XML AUTO's heuristics.
> So if you can be more specific of what changes you fear, I can give you a
> more definitive answer.
> Changes that may happen in the future include addition or removal or certa
in
> namespace declarations, changing order of attributes. But we are not
> planning on changing the resultshapes of the different modes.
> Best regards
> Michael
> "Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in messag
e
> news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
>
>
Can I trust Microsoft for FOR XML AUTO or FOR XML RAW ?
Hi,
I have been there a situation of an apprehension that Microsoft may issue
some patch or hotfix in future for SQL SERVER, that will change the shape of
XML results yielded by FOR XML AUTO or FOR XML RAW query.
Our query is going to be rigid in the application and the data would then be
passed through sensitive application that may crash if xml is not valid, we
have many types of xmls so we cannot create schema for each and every guy and
same with EXPLICIT.
Is this superstition valid that I shouldnt trust Microsoft here ?
Any input in this will sincerely be appreciated.
Fahad
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
FOR XML AUTO and FOR XML RAW results are pretty well defined, since SQL
2000. It's doubtful these would change in the current version of SQL Server
(2005) or espcially in 2000. A lot of people have already written
applications that use this functionality which would surely break if they
changed it. However the results are subject to change if your schema
changes which is probably a much more likely situation.
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
I would recommend using FOR XML PATH if you have SQL 2005. It's easy to
use, uses XPath notation to define your XML, and you can easily update or
modify it if your schema changes.
> Is this superstition valid that I shouldnt trust Microsoft here ?
Like I said, if they change this in a Service Pack (and it's been around
since SQL 2000), they are going to have a lot of unhappy customers who have
invested a lot of time and money in building applications to use it. OTOH,
one could say the same thing about COM and VB 6
At any rate I wouldn't
worry too much about it until at least the next major version release.
|||"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
I know Microsoft occasionally make breaking changes but normally they go the
other way, everything has to be backwards compatible even to the detriment
of the latest version.
Have you any specific reason for worrying that the FOR XML statements are
going to be modified?
Joe Fawcett (MVP - XML)
http://joe.fawcett.name
|||This seems like a strange thing to worry about. Aside from the basic issue
of how else would you represent a simple result set as XML, what motivation
would there be to ever changing this? What would happen if Microsoft did
this? There would be thousands of blog entries, newsgroup postings, and
news articles vilifying Microsoft for sticking it to the little guy, the
stock would drop, hundreds of employees would have to change their
retirement plans, and the SQL team would be hated by the rest of Microsoft.
Contrast this with the alternative of not changing code that works well
already and it makes changing the format a poor alternative.
Reading between the lines of your post makes me worry that you plan to do
some kind of roll your own text parsing instead of using a real XML parser.
If this is true then there could be an issue. While the results will be
semantically the same, it's hard to guarantee character for character
compatibility forever. If you want to do your own parsing you are better
off using something like comma separated values.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Reading between the lines of your post makes me worry that you plan to do
> some kind of roll your own text parsing instead of using a real XML
> parser. If this is true then there could be an issue. While the results
> will be semantically the same, it's hard to guarantee character for
> character compatibility forever. If you want to do your own parsing you
> are better off using something like comma separated values.
Do you see this being a problem if the OP is using Unicode?
|||Could you expand a bit on what you mean? I'm not sure how Unicode fits into
the question.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:%238jjscTSHHA.5060@.TK2MSFTNGP06.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Do you see this being a problem if the OP is using Unicode?
>
|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> Could you expand a bit on what you mean? I'm not sure how Unicode fits
> into the question.
"While the results will be semantically the same, it's hard to guarantee
character for character compatibility forever."
I assumed you were talking about character sets, code pages, etc., in your
"character for character compatibility" statement. Did I misunderstand?
|||No, I was talking about white space and namespace prefixes, etc. These are
the things that break when people write their own parsers instead of using a
full XML parser.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:uvLHAwWSHHA.3948@.TK2MSFTNGP05.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> "While the results will be semantically the same, it's hard to guarantee
> character for character compatibility forever."
> I assumed you were talking about character sets, code pages, etc., in your
> "character for character compatibility" statement. Did I misunderstand?
>
|||As the program manager still responsible for FOR XML, we are not planning on
changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unless
we guard it by a backwards-compatibility flag and will document the changed
behaviour ahead of time).
Between SQL Server 2000 and 2005 we did a few changes, mostly along the
lines of entitization changes. We had one breaking change in how FOR XML
AUTO dealt with subqueries and views that caused some pain, but was actually
a bug fix in the design of FOR XML AUTO's heuristics.
So if you can be more specific of what changes you fear, I can give you a
more definitive answer.
Changes that may happen in the future include addition or removal or certain
namespace declarations, changing order of attributes. But we are not
planning on changing the resultshapes of the different modes.
Best regards
Michael
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
|||Thankyou very much for your interest in helping me Michael and other guys too.
Well I am getting simple shaped XML from a single table which we then
transform using XSL. The changes which I am anticipating include
Adding any namespace to data element that will make our XPath expressions
useless. We will NEVER be able to update XPaths and issue new release of our
software once it is burnt into the hardware.
Changes in the source tree, again it will require us to update XSL.
"Michael Rys [MSFT]" wrote:
> As the program manager still responsible for FOR XML, we are not planning on
> changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unless
> we guard it by a backwards-compatibility flag and will document the changed
> behaviour ahead of time).
> Between SQL Server 2000 and 2005 we did a few changes, mostly along the
> lines of entitization changes. We had one breaking change in how FOR XML
> AUTO dealt with subqueries and views that caused some pain, but was actually
> a bug fix in the design of FOR XML AUTO's heuristics.
> So if you can be more specific of what changes you fear, I can give you a
> more definitive answer.
> Changes that may happen in the future include addition or removal or certain
> namespace declarations, changing order of attributes. But we are not
> planning on changing the resultshapes of the different modes.
> Best regards
> Michael
> "Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
> news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
>
>
I have been there a situation of an apprehension that Microsoft may issue
some patch or hotfix in future for SQL SERVER, that will change the shape of
XML results yielded by FOR XML AUTO or FOR XML RAW query.
Our query is going to be rigid in the application and the data would then be
passed through sensitive application that may crash if xml is not valid, we
have many types of xmls so we cannot create schema for each and every guy and
same with EXPLICIT.
Is this superstition valid that I shouldnt trust Microsoft here ?
Any input in this will sincerely be appreciated.
Fahad
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
FOR XML AUTO and FOR XML RAW results are pretty well defined, since SQL
2000. It's doubtful these would change in the current version of SQL Server
(2005) or espcially in 2000. A lot of people have already written
applications that use this functionality which would surely break if they
changed it. However the results are subject to change if your schema
changes which is probably a much more likely situation.
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
I would recommend using FOR XML PATH if you have SQL 2005. It's easy to
use, uses XPath notation to define your XML, and you can easily update or
modify it if your schema changes.
> Is this superstition valid that I shouldnt trust Microsoft here ?
Like I said, if they change this in a Service Pack (and it's been around
since SQL 2000), they are going to have a lot of unhappy customers who have
invested a lot of time and money in building applications to use it. OTOH,
one could say the same thing about COM and VB 6
At any rate I wouldn'tworry too much about it until at least the next major version release.
|||"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
I know Microsoft occasionally make breaking changes but normally they go the
other way, everything has to be backwards compatible even to the detriment
of the latest version.
Have you any specific reason for worrying that the FOR XML statements are
going to be modified?
Joe Fawcett (MVP - XML)
http://joe.fawcett.name
|||This seems like a strange thing to worry about. Aside from the basic issue
of how else would you represent a simple result set as XML, what motivation
would there be to ever changing this? What would happen if Microsoft did
this? There would be thousands of blog entries, newsgroup postings, and
news articles vilifying Microsoft for sticking it to the little guy, the
stock would drop, hundreds of employees would have to change their
retirement plans, and the SQL team would be hated by the rest of Microsoft.
Contrast this with the alternative of not changing code that works well
already and it makes changing the format a poor alternative.
Reading between the lines of your post makes me worry that you plan to do
some kind of roll your own text parsing instead of using a real XML parser.
If this is true then there could be an issue. While the results will be
semantically the same, it's hard to guarantee character for character
compatibility forever. If you want to do your own parsing you are better
off using something like comma separated values.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Reading between the lines of your post makes me worry that you plan to do
> some kind of roll your own text parsing instead of using a real XML
> parser. If this is true then there could be an issue. While the results
> will be semantically the same, it's hard to guarantee character for
> character compatibility forever. If you want to do your own parsing you
> are better off using something like comma separated values.
Do you see this being a problem if the OP is using Unicode?
|||Could you expand a bit on what you mean? I'm not sure how Unicode fits into
the question.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:%238jjscTSHHA.5060@.TK2MSFTNGP06.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:OpxtSS7RHHA.4832@.TK2MSFTNGP03.phx.gbl...
> Do you see this being a problem if the OP is using Unicode?
>
|||"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> Could you expand a bit on what you mean? I'm not sure how Unicode fits
> into the question.
"While the results will be semantically the same, it's hard to guarantee
character for character compatibility forever."
I assumed you were talking about character sets, code pages, etc., in your
"character for character compatibility" statement. Did I misunderstand?
|||No, I was talking about white space and namespace prefixes, etc. These are
the things that break when people write their own parsers instead of using a
full XML parser.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Mike C#" <xyz@.xyz.com> wrote in message
news:uvLHAwWSHHA.3948@.TK2MSFTNGP05.phx.gbl...
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:O8Ac8EUSHHA.3592@.TK2MSFTNGP06.phx.gbl...
> "While the results will be semantically the same, it's hard to guarantee
> character for character compatibility forever."
> I assumed you were talking about character sets, code pages, etc., in your
> "character for character compatibility" statement. Did I misunderstand?
>
|||As the program manager still responsible for FOR XML, we are not planning on
changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unless
we guard it by a backwards-compatibility flag and will document the changed
behaviour ahead of time).
Between SQL Server 2000 and 2005 we did a few changes, mostly along the
lines of entitization changes. We had one breaking change in how FOR XML
AUTO dealt with subqueries and views that caused some pain, but was actually
a bug fix in the design of FOR XML AUTO's heuristics.
So if you can be more specific of what changes you fear, I can give you a
more definitive answer.
Changes that may happen in the future include addition or removal or certain
namespace declarations, changing order of attributes. But we are not
planning on changing the resultshapes of the different modes.
Best regards
Michael
"Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
> Hi,
> I have been there a situation of an apprehension that Microsoft may issue
> some patch or hotfix in future for SQL SERVER, that will change the shape
> of
> XML results yielded by FOR XML AUTO or FOR XML RAW query.
>
> Our query is going to be rigid in the application and the data would then
> be
> passed through sensitive application that may crash if xml is not valid,
> we
> have many types of xmls so we cannot create schema for each and every guy
> and
> same with EXPLICIT.
> Is this superstition valid that I shouldnt trust Microsoft here ?
>
> Any input in this will sincerely be appreciated.
>
> Fahad
>
|||Thankyou very much for your interest in helping me Michael and other guys too.
Well I am getting simple shaped XML from a single table which we then
transform using XSL. The changes which I am anticipating include
Adding any namespace to data element that will make our XPath expressions
useless. We will NEVER be able to update XPaths and issue new release of our
software once it is burnt into the hardware.
Changes in the source tree, again it will require us to update XSL.
"Michael Rys [MSFT]" wrote:
> As the program manager still responsible for FOR XML, we are not planning on
> changing the XML infoset generated by FOR XML RAW, EXPLICIT or PATH (unless
> we guard it by a backwards-compatibility flag and will document the changed
> behaviour ahead of time).
> Between SQL Server 2000 and 2005 we did a few changes, mostly along the
> lines of entitization changes. We had one breaking change in how FOR XML
> AUTO dealt with subqueries and views that caused some pain, but was actually
> a bug fix in the design of FOR XML AUTO's heuristics.
> So if you can be more specific of what changes you fear, I can give you a
> more definitive answer.
> Changes that may happen in the future include addition or removal or certain
> namespace declarations, changing order of attributes. But we are not
> planning on changing the resultshapes of the different modes.
> Best regards
> Michael
> "Fahad Ashfaque" <FahadAshfaque@.discussions.microsoft.com> wrote in message
> news:86415A5A-428D-48DF-9175-114E9E0030F7@.microsoft.com...
>
>
Can I specify location of noise file?
I would like to know if I can change the location of a noise file on a
per-database (or filegroup) level?
My situation is this:
I have two databases operating on the same machine, same language, same
instance, different file groups. I have one application (using one of the
databases) that has a list of words that I want FTS to ignore when
searching. I have another application (using the othe database) theat not
only should include some of those words in its searching, but has its own
list of words to ignore.
Is what I want to do possible?
Any help is appreciated
Thanks in advance.
WALDO
Waldo,
While it is not possible to move or have duplicate noise word files in SQL
Server 2000 (post SELECT @.@.version output), you may be able to achieve your
goals via using US_English (noise.enu) for one database's FT-enabled tables
and UK_English for another database's FT-enabled table as both noise word
files are both English based.
You can reference different languages via "Language for Word Breaker" and
therefore different noise word files for each table. I
believe I posted an answer to your previous and differently worded question
as:
For SQL Server 2000, you could define a table in DATABASE A to use "British
English", i.e, the noise.eng noise word file, and add your custom noise
words here and when you create the FT Catalog, you define the "British
English" for that column. While, in DATABASE B, you would use US English and
noise.enu. This should meet your requirements
FYI, the noise word file locations are controlled via registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ContentIndex Common\LanguageResources\O
verride\SQLServer\English (United States)
NoiseFile value= F:\MSSQL80\MSSQL\FTData\SQLServer\Config\noise.enu
Hope that helps!
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> I would like to know if I can change the location of a noise file on a
> per-database (or filegroup) level?
> My situation is this:
> I have two databases operating on the same machine, same language,
same
> instance, different file groups. I have one application (using one of the
> databases) that has a list of words that I want FTS to ignore when
> searching. I have another application (using the othe database) theat not
> only should include some of those words in its searching, but has its own
> list of words to ignore.
> Is what I want to do possible?
> Any help is appreciated
> Thanks in advance.
> WALDO
>
|||You can use the US English word breaker for one, and the UK English word
breaker for another. This should work for you are you appear to be in PA.
The UK and US English word lists, breakers and stemmers are almost
identical.
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
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:%23r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> I would like to know if I can change the location of a noise file on a
> per-database (or filegroup) level?
> My situation is this:
> I have two databases operating on the same machine, same language,
same
> instance, different file groups. I have one application (using one of the
> databases) that has a list of words that I want FTS to ignore when
> searching. I have another application (using the othe database) theat not
> only should include some of those words in its searching, but has its own
> list of words to ignore.
> Is what I want to do possible?
> Any help is appreciated
> Thanks in advance.
> WALDO
>
|||How did you know that I was in PA?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eO64FpNnFHA.1968@.TK2MSFTNGP14.phx.gbl...[vbcol=seagreen]
> You can use the US English word breaker for one, and the UK English word
> breaker for another. This should work for you are you appear to be in PA.
> The UK and US English word lists, breakers and stemmers are almost
> identical.
> --
> 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
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:%23r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> same
the[vbcol=seagreen]
not[vbcol=seagreen]
own
>
|||Wow, just the 2 people I wanted to reply to this.
SELECT @.@.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.0 (Build 2195: Service Pack 4)
I was actually debating using a different laguage word-breaker/stemmer for
each database. Is it possible to create my own word-breaker/stemmer COM
classes as long as they implement the correct interfaces?
For instance, have my own "language" with a fictional locale id, create the
registry entries for my language, then supply a "noise.myLang1" file for the
noise words.
Is that possible?
"John Kane" <jt-kane@.comcast.net> wrote in message
news:u5pf6UInFHA.1968@.TK2MSFTNGP14.phx.gbl...
> Waldo,
> While it is not possible to move or have duplicate noise word files in SQL
> Server 2000 (post SELECT @.@.version output), you may be able to achieve
your
> goals via using US_English (noise.enu) for one database's FT-enabled
tables
> and UK_English for another database's FT-enabled table as both noise word
> files are both English based.
> You can reference different languages via "Language for Word Breaker" and
> therefore different noise word files for each table. I
> believe I posted an answer to your previous and differently worded
question
> as:
> For SQL Server 2000, you could define a table in DATABASE A to use
"British
> English", i.e, the noise.eng noise word file, and add your custom noise
> words here and when you create the FT Catalog, you define the "British
> English" for that column. While, in DATABASE B, you would use US English
and
> noise.enu. This should meet your requirements
> FYI, the noise word file locations are controlled via registry keys:
>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ContentIndex Common\LanguageResources\O[vbcol=seagreen]
> verride\SQLServer\English (United States)
> NoiseFile value= F:\MSSQL80\MSSQL\FTData\SQLServer\Config\noise.enu
> Hope that helps!
> John
> --
> SQL Full Text Search Blog
> http://spaces.msn.com/members/jtkane/
>
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> same
the[vbcol=seagreen]
not[vbcol=seagreen]
own
>
|||There sheer genius of your post make it unmistakably someone from PA. That
and your nntp headers
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
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:%23S1IQVQnFHA.2580@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> How did you know that I was in PA?
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:eO64FpNnFHA.1968@.TK2MSFTNGP14.phx.gbl...
PA.
> the
> not
> own
>
|||Little off topic, (ok very)
Just out of sheer morbid curiosity, what in my NNTP headers indicates PA? I
would be interested in knowing just for my own personal gratification. This
is what mine says when I look at them.
From: "Rob Mayo" <NOSPAM@.NOSPAM.com>
Subject: Can I specify location of noise file?
Date: Mon, 8 Aug 2005 12:40:38 -0400
Lines: 19
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Message-ID: <#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.sqlserver.fulltext
NNTP-Posting-Host: nat.westonsolutions.com 162.43.198.100
Path: TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.fulltext:15271
I see in yours that they came from Toronto
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%235nffZQnFHA.2180@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> There sheer genius of your post make it unmistakably someone from PA. That
> and your nntp headers
> --
> 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
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:%23S1IQVQnFHA.2580@.TK2MSFTNGP09.phx.gbl...
word[vbcol=seagreen]
> PA.
a[vbcol=seagreen]
language,[vbcol=seagreen]
of[vbcol=seagreen]
theat[vbcol=seagreen]
its
>
|||I did a tracert on your IP
C:\Documents and Settings\hcotter>tracert 162.43.198.100
Tracing route to nat.westonsolutions.com [162.43.198.100]
over a maximum of 30 hops:
1 6 ms 6 ms 8 ms 172.16.1.1
2 20 ms 40 ms 16 ms 64.230.197.195
3 49 ms 41 ms 22 ms 64.230.234.37
4 15 ms 15 ms 13 ms 64.230.221.105
5 31 ms 63 ms 62 ms core2-chicago23-pos10-0.in.bellnexxia.net
[206.1
08.103.118]
6 57 ms 30 ms 25 ms bx2-chicago23-pos10-0.in.bellnexxia.net
[206.108
..103.122]
7 43 ms 58 ms 35 ms sl-gw36-chi-12-0.sprintlink.net
[160.81.109.193]
8 25 ms 36 ms 34 ms sl-bb20-chi-5-0.sprintlink.net
[144.232.26.69]
9 25 ms 27 ms 96 ms sl-bb25-chi-8-0.sprintlink.net
[144.232.26.113]
10 46 ms 45 ms 58 ms sl-bb26-rly-10-0.sprintlink.net
[144.232.20.88]
11 47 ms 68 ms 79 ms sl-bb24-pen-12-0.sprintlink.net
[144.232.20.110]
12 99 ms 74 ms 69 ms sl-bb20-pen-8-0.sprintlink.net
[144.232.5.165]
13 83 ms 54 ms 73 ms sl-gw2-pen-9-0.sprintlink.net [144.232.5.10]
14 47 ms 45 ms 47 ms sl-internap-121-0.sprintlink.net
[144.223.16.234
]
15 52 ms 45 ms 45 ms border1.fe0-0-bbnet1.phi.pnap.net
[216.52.64.4]
16 * rfweston-4.border1.phi.pnap.net [216.52.66.38] reports:
Destinati
on net unreachable.
Trace complete.
I notice a lot of references to pen and phi in there.
I am actually based out of NJ, I am at a client site north of Toronto.
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
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:On3aS6QnFHA.2916@.TK2MSFTNGP14.phx.gbl...
> Little off topic, (ok very)
> Just out of sheer morbid curiosity, what in my NNTP headers indicates PA?
I
> would be interested in knowing just for my own personal gratification.
This[vbcol=seagreen]
> is what mine says when I look at them.
> From: "Rob Mayo" <NOSPAM@.NOSPAM.com>
> Subject: Can I specify location of noise file?
> Date: Mon, 8 Aug 2005 12:40:38 -0400
> Lines: 19
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1506
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
> Message-ID: <#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl>
> Newsgroups: microsoft.public.sqlserver.fulltext
> NNTP-Posting-Host: nat.westonsolutions.com 162.43.198.100
> Path: TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
> Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.fulltext:15271
> I see in yours that they came from Toronto
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%235nffZQnFHA.2180@.TK2MSFTNGP15.phx.gbl...
That[vbcol=seagreen]
> word
in[vbcol=seagreen]
on
> a
> language,
> of
> theat
> its
>
|||You're welcome, Rob,
First of all, thank you for the @.@.version info as this tell me that you're
using SQL 2000 SP3 on Win2K SP4. The OS-platform info is important as with
SQL 2000, the OS-supplied English wordbreaker is (in this case)
infosoft.dll.
As for having your own "fictional" language and fictional locale id with
corresponding registry keys, etc., that may be possible as that is how the
IFilter sample apps are setup to demonstrate the use of the interfaces. The
following links should be helpful in that regard:
Word Breaker and Stemmer Sample
http://msdn.microsoft.com/library/de...nario_3e91.asp
Implementing a Stemmer
http://msdn.microsoft.com/library/de...nario_1bg3.asp
Implementing a Word Breaker
http://msdn.microsoft.com/library/de...nario_54bp.asp
About Language Resources
http://msdn.microsoft.com/library/de...nario_3u2c.asp
Troubleshooting Language Resources
http://msdn.microsoft.com/library/de...nario_5dwz.asp
As for integrating the fictional "language" into SQL Server FTS in a real
production environment that uses "English" as the actual text language, I'm
not sure that is possible. However, feel free to ping me directly if you
want to discuss this in more detail.
Thanks,
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:Ovl4yYQnFHA.4064@.TK2MSFTNGP10.phx.gbl...
> Wow, just the 2 people I wanted to reply to this.
> SELECT @.@.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.0 (Build 2195: Service Pack 4)
> I was actually debating using a different laguage word-breaker/stemmer for
> each database. Is it possible to create my own word-breaker/stemmer COM
> classes as long as they implement the correct interfaces?
> For instance, have my own "language" with a fictional locale id, create
the
> registry entries for my language, then supply a "noise.myLang1" file for
the[vbcol=seagreen]
> noise words.
> Is that possible?
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:u5pf6UInFHA.1968@.TK2MSFTNGP14.phx.gbl...
SQL[vbcol=seagreen]
> your
> tables
word[vbcol=seagreen]
and
> question
> "British
> and
>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ContentIndex Common\LanguageResources\O
> the
> not
> own
>
|||Damn, cool
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eh%23OlxRnFHA.3288@.TK2MSFTNGP10.phx.gbl...
> I did a tracert on your IP
> C:\Documents and Settings\hcotter>tracert 162.43.198.100
> Tracing route to nat.westonsolutions.com [162.43.198.100]
> over a maximum of 30 hops:
> 1 6 ms 6 ms 8 ms 172.16.1.1
> 2 20 ms 40 ms 16 ms 64.230.197.195
> 3 49 ms 41 ms 22 ms 64.230.234.37
> 4 15 ms 15 ms 13 ms 64.230.221.105
> 5 31 ms 63 ms 62 ms core2-chicago23-pos10-0.in.bellnexxia.net
> [206.1
> 08.103.118]
> 6 57 ms 30 ms 25 ms bx2-chicago23-pos10-0.in.bellnexxia.net
> [206.108
> .103.122]
> 7 43 ms 58 ms 35 ms sl-gw36-chi-12-0.sprintlink.net
> [160.81.109.193]
> 8 25 ms 36 ms 34 ms sl-bb20-chi-5-0.sprintlink.net
> [144.232.26.69]
> 9 25 ms 27 ms 96 ms sl-bb25-chi-8-0.sprintlink.net
> [144.232.26.113]
> 10 46 ms 45 ms 58 ms sl-bb26-rly-10-0.sprintlink.net
> [144.232.20.88]
> 11 47 ms 68 ms 79 ms sl-bb24-pen-12-0.sprintlink.net
> [144.232.20.110]
> 12 99 ms 74 ms 69 ms sl-bb20-pen-8-0.sprintlink.net
> [144.232.5.165]
> 13 83 ms 54 ms 73 ms sl-gw2-pen-9-0.sprintlink.net
[144.232.5.10][vbcol=seagreen]
> 14 47 ms 45 ms 47 ms sl-internap-121-0.sprintlink.net
> [144.223.16.234
> ]
> 15 52 ms 45 ms 45 ms border1.fe0-0-bbnet1.phi.pnap.net
> [216.52.64.4]
> 16 * rfweston-4.border1.phi.pnap.net [216.52.66.38] reports:
> Destinati
> on net unreachable.
> Trace complete.
> I notice a lot of references to pen and phi in there.
> I am actually based out of NJ, I am at a client site north of Toronto.
> --
> 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
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:On3aS6QnFHA.2916@.TK2MSFTNGP14.phx.gbl...
PA?[vbcol=seagreen]
> I
> This
> That
English[vbcol=seagreen]
> in
file[vbcol=seagreen]
> on
one[vbcol=seagreen]
when[vbcol=seagreen]
has
>
per-database (or filegroup) level?
My situation is this:
I have two databases operating on the same machine, same language, same
instance, different file groups. I have one application (using one of the
databases) that has a list of words that I want FTS to ignore when
searching. I have another application (using the othe database) theat not
only should include some of those words in its searching, but has its own
list of words to ignore.
Is what I want to do possible?
Any help is appreciated
Thanks in advance.
WALDO
Waldo,
While it is not possible to move or have duplicate noise word files in SQL
Server 2000 (post SELECT @.@.version output), you may be able to achieve your
goals via using US_English (noise.enu) for one database's FT-enabled tables
and UK_English for another database's FT-enabled table as both noise word
files are both English based.
You can reference different languages via "Language for Word Breaker" and
therefore different noise word files for each table. I
believe I posted an answer to your previous and differently worded question
as:
For SQL Server 2000, you could define a table in DATABASE A to use "British
English", i.e, the noise.eng noise word file, and add your custom noise
words here and when you create the FT Catalog, you define the "British
English" for that column. While, in DATABASE B, you would use US English and
noise.enu. This should meet your requirements
FYI, the noise word file locations are controlled via registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ContentIndex Common\LanguageResources\O
verride\SQLServer\English (United States)
NoiseFile value= F:\MSSQL80\MSSQL\FTData\SQLServer\Config\noise.enu
Hope that helps!
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> I would like to know if I can change the location of a noise file on a
> per-database (or filegroup) level?
> My situation is this:
> I have two databases operating on the same machine, same language,
same
> instance, different file groups. I have one application (using one of the
> databases) that has a list of words that I want FTS to ignore when
> searching. I have another application (using the othe database) theat not
> only should include some of those words in its searching, but has its own
> list of words to ignore.
> Is what I want to do possible?
> Any help is appreciated
> Thanks in advance.
> WALDO
>
|||You can use the US English word breaker for one, and the UK English word
breaker for another. This should work for you are you appear to be in PA.
The UK and US English word lists, breakers and stemmers are almost
identical.
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
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:%23r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> I would like to know if I can change the location of a noise file on a
> per-database (or filegroup) level?
> My situation is this:
> I have two databases operating on the same machine, same language,
same
> instance, different file groups. I have one application (using one of the
> databases) that has a list of words that I want FTS to ignore when
> searching. I have another application (using the othe database) theat not
> only should include some of those words in its searching, but has its own
> list of words to ignore.
> Is what I want to do possible?
> Any help is appreciated
> Thanks in advance.
> WALDO
>
|||How did you know that I was in PA?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eO64FpNnFHA.1968@.TK2MSFTNGP14.phx.gbl...[vbcol=seagreen]
> You can use the US English word breaker for one, and the UK English word
> breaker for another. This should work for you are you appear to be in PA.
> The UK and US English word lists, breakers and stemmers are almost
> identical.
> --
> 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
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:%23r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> same
the[vbcol=seagreen]
not[vbcol=seagreen]
own
>
|||Wow, just the 2 people I wanted to reply to this.
SELECT @.@.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.0 (Build 2195: Service Pack 4)
I was actually debating using a different laguage word-breaker/stemmer for
each database. Is it possible to create my own word-breaker/stemmer COM
classes as long as they implement the correct interfaces?
For instance, have my own "language" with a fictional locale id, create the
registry entries for my language, then supply a "noise.myLang1" file for the
noise words.
Is that possible?
"John Kane" <jt-kane@.comcast.net> wrote in message
news:u5pf6UInFHA.1968@.TK2MSFTNGP14.phx.gbl...
> Waldo,
> While it is not possible to move or have duplicate noise word files in SQL
> Server 2000 (post SELECT @.@.version output), you may be able to achieve
your
> goals via using US_English (noise.enu) for one database's FT-enabled
tables
> and UK_English for another database's FT-enabled table as both noise word
> files are both English based.
> You can reference different languages via "Language for Word Breaker" and
> therefore different noise word files for each table. I
> believe I posted an answer to your previous and differently worded
question
> as:
> For SQL Server 2000, you could define a table in DATABASE A to use
"British
> English", i.e, the noise.eng noise word file, and add your custom noise
> words here and when you create the FT Catalog, you define the "British
> English" for that column. While, in DATABASE B, you would use US English
and
> noise.enu. This should meet your requirements
> FYI, the noise word file locations are controlled via registry keys:
>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ContentIndex Common\LanguageResources\O[vbcol=seagreen]
> verride\SQLServer\English (United States)
> NoiseFile value= F:\MSSQL80\MSSQL\FTData\SQLServer\Config\noise.enu
> Hope that helps!
> John
> --
> SQL Full Text Search Blog
> http://spaces.msn.com/members/jtkane/
>
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl...
> same
the[vbcol=seagreen]
not[vbcol=seagreen]
own
>
|||There sheer genius of your post make it unmistakably someone from PA. That
and your nntp headers
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
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:%23S1IQVQnFHA.2580@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> How did you know that I was in PA?
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:eO64FpNnFHA.1968@.TK2MSFTNGP14.phx.gbl...
PA.
> the
> not
> own
>
|||Little off topic, (ok very)
Just out of sheer morbid curiosity, what in my NNTP headers indicates PA? I
would be interested in knowing just for my own personal gratification. This
is what mine says when I look at them.
From: "Rob Mayo" <NOSPAM@.NOSPAM.com>
Subject: Can I specify location of noise file?
Date: Mon, 8 Aug 2005 12:40:38 -0400
Lines: 19
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Message-ID: <#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.sqlserver.fulltext
NNTP-Posting-Host: nat.westonsolutions.com 162.43.198.100
Path: TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.fulltext:15271
I see in yours that they came from Toronto
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%235nffZQnFHA.2180@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> There sheer genius of your post make it unmistakably someone from PA. That
> and your nntp headers
> --
> 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
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:%23S1IQVQnFHA.2580@.TK2MSFTNGP09.phx.gbl...
word[vbcol=seagreen]
> PA.
a[vbcol=seagreen]
language,[vbcol=seagreen]
of[vbcol=seagreen]
theat[vbcol=seagreen]
its
>
|||I did a tracert on your IP
C:\Documents and Settings\hcotter>tracert 162.43.198.100
Tracing route to nat.westonsolutions.com [162.43.198.100]
over a maximum of 30 hops:
1 6 ms 6 ms 8 ms 172.16.1.1
2 20 ms 40 ms 16 ms 64.230.197.195
3 49 ms 41 ms 22 ms 64.230.234.37
4 15 ms 15 ms 13 ms 64.230.221.105
5 31 ms 63 ms 62 ms core2-chicago23-pos10-0.in.bellnexxia.net
[206.1
08.103.118]
6 57 ms 30 ms 25 ms bx2-chicago23-pos10-0.in.bellnexxia.net
[206.108
..103.122]
7 43 ms 58 ms 35 ms sl-gw36-chi-12-0.sprintlink.net
[160.81.109.193]
8 25 ms 36 ms 34 ms sl-bb20-chi-5-0.sprintlink.net
[144.232.26.69]
9 25 ms 27 ms 96 ms sl-bb25-chi-8-0.sprintlink.net
[144.232.26.113]
10 46 ms 45 ms 58 ms sl-bb26-rly-10-0.sprintlink.net
[144.232.20.88]
11 47 ms 68 ms 79 ms sl-bb24-pen-12-0.sprintlink.net
[144.232.20.110]
12 99 ms 74 ms 69 ms sl-bb20-pen-8-0.sprintlink.net
[144.232.5.165]
13 83 ms 54 ms 73 ms sl-gw2-pen-9-0.sprintlink.net [144.232.5.10]
14 47 ms 45 ms 47 ms sl-internap-121-0.sprintlink.net
[144.223.16.234
]
15 52 ms 45 ms 45 ms border1.fe0-0-bbnet1.phi.pnap.net
[216.52.64.4]
16 * rfweston-4.border1.phi.pnap.net [216.52.66.38] reports:
Destinati
on net unreachable.
Trace complete.
I notice a lot of references to pen and phi in there.
I am actually based out of NJ, I am at a client site north of Toronto.
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
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:On3aS6QnFHA.2916@.TK2MSFTNGP14.phx.gbl...
> Little off topic, (ok very)
> Just out of sheer morbid curiosity, what in my NNTP headers indicates PA?
I
> would be interested in knowing just for my own personal gratification.
This[vbcol=seagreen]
> is what mine says when I look at them.
> From: "Rob Mayo" <NOSPAM@.NOSPAM.com>
> Subject: Can I specify location of noise file?
> Date: Mon, 8 Aug 2005 12:40:38 -0400
> Lines: 19
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1506
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
> Message-ID: <#r4rpfDnFHA.860@.TK2MSFTNGP12.phx.gbl>
> Newsgroups: microsoft.public.sqlserver.fulltext
> NNTP-Posting-Host: nat.westonsolutions.com 162.43.198.100
> Path: TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
> Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.fulltext:15271
> I see in yours that they came from Toronto
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%235nffZQnFHA.2180@.TK2MSFTNGP15.phx.gbl...
That[vbcol=seagreen]
> word
in[vbcol=seagreen]
on
> a
> language,
> of
> theat
> its
>
|||You're welcome, Rob,
First of all, thank you for the @.@.version info as this tell me that you're
using SQL 2000 SP3 on Win2K SP4. The OS-platform info is important as with
SQL 2000, the OS-supplied English wordbreaker is (in this case)
infosoft.dll.
As for having your own "fictional" language and fictional locale id with
corresponding registry keys, etc., that may be possible as that is how the
IFilter sample apps are setup to demonstrate the use of the interfaces. The
following links should be helpful in that regard:
Word Breaker and Stemmer Sample
http://msdn.microsoft.com/library/de...nario_3e91.asp
Implementing a Stemmer
http://msdn.microsoft.com/library/de...nario_1bg3.asp
Implementing a Word Breaker
http://msdn.microsoft.com/library/de...nario_54bp.asp
About Language Resources
http://msdn.microsoft.com/library/de...nario_3u2c.asp
Troubleshooting Language Resources
http://msdn.microsoft.com/library/de...nario_5dwz.asp
As for integrating the fictional "language" into SQL Server FTS in a real
production environment that uses "English" as the actual text language, I'm
not sure that is possible. However, feel free to ping me directly if you
want to discuss this in more detail.
Thanks,
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
news:Ovl4yYQnFHA.4064@.TK2MSFTNGP10.phx.gbl...
> Wow, just the 2 people I wanted to reply to this.
> SELECT @.@.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.0 (Build 2195: Service Pack 4)
> I was actually debating using a different laguage word-breaker/stemmer for
> each database. Is it possible to create my own word-breaker/stemmer COM
> classes as long as they implement the correct interfaces?
> For instance, have my own "language" with a fictional locale id, create
the
> registry entries for my language, then supply a "noise.myLang1" file for
the[vbcol=seagreen]
> noise words.
> Is that possible?
>
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:u5pf6UInFHA.1968@.TK2MSFTNGP14.phx.gbl...
SQL[vbcol=seagreen]
> your
> tables
word[vbcol=seagreen]
and
> question
> "British
> and
>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ContentIndex Common\LanguageResources\O
> the
> not
> own
>
|||Damn, cool
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:eh%23OlxRnFHA.3288@.TK2MSFTNGP10.phx.gbl...
> I did a tracert on your IP
> C:\Documents and Settings\hcotter>tracert 162.43.198.100
> Tracing route to nat.westonsolutions.com [162.43.198.100]
> over a maximum of 30 hops:
> 1 6 ms 6 ms 8 ms 172.16.1.1
> 2 20 ms 40 ms 16 ms 64.230.197.195
> 3 49 ms 41 ms 22 ms 64.230.234.37
> 4 15 ms 15 ms 13 ms 64.230.221.105
> 5 31 ms 63 ms 62 ms core2-chicago23-pos10-0.in.bellnexxia.net
> [206.1
> 08.103.118]
> 6 57 ms 30 ms 25 ms bx2-chicago23-pos10-0.in.bellnexxia.net
> [206.108
> .103.122]
> 7 43 ms 58 ms 35 ms sl-gw36-chi-12-0.sprintlink.net
> [160.81.109.193]
> 8 25 ms 36 ms 34 ms sl-bb20-chi-5-0.sprintlink.net
> [144.232.26.69]
> 9 25 ms 27 ms 96 ms sl-bb25-chi-8-0.sprintlink.net
> [144.232.26.113]
> 10 46 ms 45 ms 58 ms sl-bb26-rly-10-0.sprintlink.net
> [144.232.20.88]
> 11 47 ms 68 ms 79 ms sl-bb24-pen-12-0.sprintlink.net
> [144.232.20.110]
> 12 99 ms 74 ms 69 ms sl-bb20-pen-8-0.sprintlink.net
> [144.232.5.165]
> 13 83 ms 54 ms 73 ms sl-gw2-pen-9-0.sprintlink.net
[144.232.5.10][vbcol=seagreen]
> 14 47 ms 45 ms 47 ms sl-internap-121-0.sprintlink.net
> [144.223.16.234
> ]
> 15 52 ms 45 ms 45 ms border1.fe0-0-bbnet1.phi.pnap.net
> [216.52.64.4]
> 16 * rfweston-4.border1.phi.pnap.net [216.52.66.38] reports:
> Destinati
> on net unreachable.
> Trace complete.
> I notice a lot of references to pen and phi in there.
> I am actually based out of NJ, I am at a client site north of Toronto.
> --
> 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
> "Rob Mayo" <NOSPAM@.NOSPAM.com> wrote in message
> news:On3aS6QnFHA.2916@.TK2MSFTNGP14.phx.gbl...
PA?[vbcol=seagreen]
> I
> This
> That
English[vbcol=seagreen]
> in
file[vbcol=seagreen]
> on
one[vbcol=seagreen]
when[vbcol=seagreen]
has
>
Subscribe to:
Posts (Atom)