I'm working on a project for a national restaurant chain. I've built a
complex class that allows them to do various forms of sales estimations for
stores who fail to report their weekly sales. I say "complex" because it
has a detailed class hierarchy under it and performs lot of SQL Server work
inside its "black box." Using this class within a web page is working
great...
Now they want this functionality to also appear in a report, and I'm
wondering what I have to do -- never done a RS data extension and first am
wondering: Is this what I need to add this function to a report?
If the answer is "yes," is there a resource that describes in detail how to
do it, with a non-trivial example?
I'm really under the gun on this one, so I'll be grateful for any help --
thanks!
JoeI'd start with the sample reports that ship with the product. Check
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSAMPLES/htm/rss_overview_v1_631v.asp?frame=true
for details.
--
Ravi Mumulla (Microsoft)
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Joe Helmick" <joe_helmick@.4dv.net> wrote in message
news:O2r7tE5jEHA.1652@.TK2MSFTNGP09.phx.gbl...
> I'm working on a project for a national restaurant chain. I've built a
> complex class that allows them to do various forms of sales estimations
for
> stores who fail to report their weekly sales. I say "complex" because it
> has a detailed class hierarchy under it and performs lot of SQL Server
work
> inside its "black box." Using this class within a web page is working
> great...
> Now they want this functionality to also appear in a report, and I'm
> wondering what I have to do -- never done a RS data extension and first am
> wondering: Is this what I need to add this function to a report?
> If the answer is "yes," is there a resource that describes in detail how
to
> do it, with a non-trivial example?
> I'm really under the gun on this one, so I'll be grateful for any help --
> thanks!
> Joe
>|||Joe,
One option in your scenario may be to dump your object data (state) in a
database before the report is run. Unfortunately, version 1.0 of Reporting
Services doesn't support events, so to implement preprocessing you need to
get somewhat innovative. One option is to attach an expression to a property
of the report body band (it will fire before the regions get loaded). This
expression could gather the report parameters, pass it to your object which
in turn can serialize itself to the database and let the regions pick data
from there. Of course, this is a rather simplified version of what you may
need to do.
Yes, another and more elegant option is to wrap you object in a custom data
extension. This is actually very straightforward. You need to expose your
object data as a forward-only tabular stream which conforms to the
IDataReader interface. You may find my ADO.NET custom data extension
(http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=B846
8707-56EF-4864-AC51-D83FC3273FE5) useful to get you started. It comes with
step-by-step help instructions.
Hope this helps.
----
Teo Lachev, MCSD, MCT
Author: "Microsoft Reporting Services in Action"
Publisher website: http://www.manning.com/lachev
Buy it from Amazon.com: http://shrinkster.com/eq
Home page and blog: http://www.prologika.com/
----
"Joe Helmick" <joe_helmick@.4dv.net> wrote in message
news:0l1aj0h4452vd72jles53foioiqfhfdphn@.4ax.com...
> Ravi,
> Thanks, but I have all the samples and unless I missed something due
> to my newbie-ness, I don't see what I need. I don't need drilldown or
> drillthrough, and simple functions in a code-behind don't seem like
> they'd nearly fill the bill. I'm already doing cascading parameters
> from multiple datasets and stuff like that, no problem, but attaching
> functionality from a 700-line VB class with deep inheritance? I don't
> see anything like that in the samples...
> Did I miss something, or do I need another resource besides the
> samples?
> Joe
> "Ravi Mumulla \(Microsoft\)" <ravimu@.online.microsoft.com> bellowed
> forth with this wisdom for all to hear:
> > I'd start with the sample reports that ship with the product. Check
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSAMPLES/htm/rss_overview_v1_631v.asp?frame=true
> > for details.
>sql
Showing posts with label various. Show all posts
Showing posts with label various. Show all posts
Thursday, March 22, 2012
Tuesday, February 14, 2012
Distributed transaction error
We have a server, for various reasons has link to a loop back linked server.
We have dozens of stored procedures that refer to the linked server in their
code. They have worked fine for several years until a developer added an on
update/insert trigger to a table. Now, when these stored procedures execute
,
there is a distritbuted transaction error. Distributed Transaction
Coordinator is verified as being on.
Does anyone know of a way to fix this or what is going on?
Thank you.For SQL Server's OLEDB provider (SQLOLEDB), I believe that the session
option XACT_ABORT should also be on to support modifications in a
distributed transaction.
BG, SQL Server MVP
www.SolidQualityLearning.com
"Aaron" <Aaron@.discussions.microsoft.com> wrote in message
news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
> We have a server, for various reasons has link to a loop back linked
> server.
> We have dozens of stored procedures that refer to the linked server in
> their
> code. They have worked fine for several years until a developer added an
> on
> update/insert trigger to a table. Now, when these stored procedures
> execute,
> there is a distritbuted transaction error. Distributed Transaction
> Coordinator is verified as being on.
> Does anyone know of a way to fix this or what is going on?
> Thank you.|||Distributed transactions are not supported on loopback linked servers! If
itrigger is requred on a table and references another database on the same
server, hardcode the full 3 part name, ommiting server name.
"Aaron" <Aaron@.discussions.microsoft.com> wrote in message
news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
> We have a server, for various reasons has link to a loop back linked
> server.
> We have dozens of stored procedures that refer to the linked server in
> their
> code. They have worked fine for several years until a developer added an
> on
> update/insert trigger to a table. Now, when these stored procedures
> execute,
> there is a distritbuted transaction error. Distributed Transaction
> Coordinator is verified as being on.
> Does anyone know of a way to fix this or what is going on?
> Thank you.|||Thanks for the advice, however, we have tested it with XACT_ABORT set to ON.
One of our database guru's mentioned:
--start quote--
“SQL Server still sees the all the involved statements as a single
transaction and because it have a call to the linked server, it tries to
initiates it as distributed transaction.”
I read in the sql server docs that whenever two databases are involved, sql
server treats the transaction as a distributed transaction even if the
databases are on the same box
--end quote--
Example: our stored procedure has a query similar to the following:
sql1 is the loop back linked server, the database resides ON the same box,
however, for various reasons we have left the sp to reference it as a linked
server.
update mytable
set mytable.column1 = 1
where NOT EXISTS
(select id from sql1.dbo.mytable2 p where p.column = mytable.column)
The following error message is generated whenever the trigger on
update/insert is active on the table mytable. We remove the trigger and the
SP works as always:
error msg: The operation could not be performed because the OLE DB provider
'SQLOLEDB' was unable to begin a distributed transaction.
Thanks for any help you can provide.
"Itzik Ben-Gan" wrote:
> For SQL Server's OLEDB provider (SQLOLEDB), I believe that the session
> option XACT_ABORT should also be on to support modifications in a
> distributed transaction.
> --
> BG, SQL Server MVP
> www.SolidQualityLearning.com
>
> "Aaron" <Aaron@.discussions.microsoft.com> wrote in message
> news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
>
>|||I appreciate your response Farmer,
however, the trigger itself has no reference at all to the loopback linked
server. It is trying to update a simple field in a table on the same server
as the trigger. The error happens in the SP, which has worked for several
years. If you remove the trigger, the SP works again.
"Farmer" wrote:
> Distributed transactions are not supported on loopback linked servers! If
> itrigger is requred on a table and references another database on the same
> server, hardcode the full 3 part name, ommiting server name.
> "Aaron" <Aaron@.discussions.microsoft.com> wrote in message
> news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
>
>|||Any data modification statements BEGIN an implisit transactions, that is why
selects worked and update fails now. Because it is involving linked server,
it is considered distributed.
BOL
Starting Transactions
You can start transactions in Microsoft SQL ServerT as explicit,
autocommit, or implicit transactions.
Explicit transactions
Explicitly start a transaction by issuing a BEGIN TRANSACTION statement.
Autocommit transactions
This is the default mode for SQL Server. Each individual Transact-SQL
statement is committed when it completes. You do not have to specify any
statements to control transactions.
Implicit transactions
Set implicit transaction mode on through either an API function or the
Transact-SQL SET IMPLICIT_TRANSACTIONS ON statement. The next statement
automatically starts a new transaction. When that transaction is completed,
the next Transact-SQL statement starts a new transaction.
Connection modes are managed at the connection level. If one connection
changes from one transaction mode to another it has no effect on the
transaction modes of any other connection.
"Aaron" <Aaron@.discussions.microsoft.com> wrote in message
news:A8695506-E70A-4412-8417-97E91699C2A0@.microsoft.com...
> Thanks for the advice, however, we have tested it with XACT_ABORT set to
> ON.
> One of our database guru's mentioned:
> --start quote--
> "SQL Server still sees the all the involved statements as a single
> transaction and because it have a call to the linked server, it tries to
> initiates it as distributed transaction."
> I read in the sql server docs that whenever two databases are involved,
> sql
> server treats the transaction as a distributed transaction even if the
> databases are on the same box
> --end quote--
> Example: our stored procedure has a query similar to the following:
> sql1 is the loop back linked server, the database resides ON the same box,
> however, for various reasons we have left the sp to reference it as a
> linked
> server.
> update mytable
> set mytable.column1 = 1
> where NOT EXISTS
> (select id from sql1.dbo.mytable2 p where p.column = mytable.column)
> The following error message is generated whenever the trigger on
> update/insert is active on the table mytable. We remove the trigger and
> the
> SP works as always:
> error msg: The operation could not be performed because the OLE DB
> provider
> 'SQLOLEDB' was unable to begin a distributed transaction.
>
> Thanks for any help you can provide.
>
> "Itzik Ben-Gan" wrote:
>
We have dozens of stored procedures that refer to the linked server in their
code. They have worked fine for several years until a developer added an on
update/insert trigger to a table. Now, when these stored procedures execute
,
there is a distritbuted transaction error. Distributed Transaction
Coordinator is verified as being on.
Does anyone know of a way to fix this or what is going on?
Thank you.For SQL Server's OLEDB provider (SQLOLEDB), I believe that the session
option XACT_ABORT should also be on to support modifications in a
distributed transaction.
BG, SQL Server MVP
www.SolidQualityLearning.com
"Aaron" <Aaron@.discussions.microsoft.com> wrote in message
news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
> We have a server, for various reasons has link to a loop back linked
> server.
> We have dozens of stored procedures that refer to the linked server in
> their
> code. They have worked fine for several years until a developer added an
> on
> update/insert trigger to a table. Now, when these stored procedures
> execute,
> there is a distritbuted transaction error. Distributed Transaction
> Coordinator is verified as being on.
> Does anyone know of a way to fix this or what is going on?
> Thank you.|||Distributed transactions are not supported on loopback linked servers! If
itrigger is requred on a table and references another database on the same
server, hardcode the full 3 part name, ommiting server name.
"Aaron" <Aaron@.discussions.microsoft.com> wrote in message
news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
> We have a server, for various reasons has link to a loop back linked
> server.
> We have dozens of stored procedures that refer to the linked server in
> their
> code. They have worked fine for several years until a developer added an
> on
> update/insert trigger to a table. Now, when these stored procedures
> execute,
> there is a distritbuted transaction error. Distributed Transaction
> Coordinator is verified as being on.
> Does anyone know of a way to fix this or what is going on?
> Thank you.|||Thanks for the advice, however, we have tested it with XACT_ABORT set to ON.
One of our database guru's mentioned:
--start quote--
“SQL Server still sees the all the involved statements as a single
transaction and because it have a call to the linked server, it tries to
initiates it as distributed transaction.”
I read in the sql server docs that whenever two databases are involved, sql
server treats the transaction as a distributed transaction even if the
databases are on the same box
--end quote--
Example: our stored procedure has a query similar to the following:
sql1 is the loop back linked server, the database resides ON the same box,
however, for various reasons we have left the sp to reference it as a linked
server.
update mytable
set mytable.column1 = 1
where NOT EXISTS
(select id from sql1.dbo.mytable2 p where p.column = mytable.column)
The following error message is generated whenever the trigger on
update/insert is active on the table mytable. We remove the trigger and the
SP works as always:
error msg: The operation could not be performed because the OLE DB provider
'SQLOLEDB' was unable to begin a distributed transaction.
Thanks for any help you can provide.
"Itzik Ben-Gan" wrote:
> For SQL Server's OLEDB provider (SQLOLEDB), I believe that the session
> option XACT_ABORT should also be on to support modifications in a
> distributed transaction.
> --
> BG, SQL Server MVP
> www.SolidQualityLearning.com
>
> "Aaron" <Aaron@.discussions.microsoft.com> wrote in message
> news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
>
>|||I appreciate your response Farmer,
however, the trigger itself has no reference at all to the loopback linked
server. It is trying to update a simple field in a table on the same server
as the trigger. The error happens in the SP, which has worked for several
years. If you remove the trigger, the SP works again.
"Farmer" wrote:
> Distributed transactions are not supported on loopback linked servers! If
> itrigger is requred on a table and references another database on the same
> server, hardcode the full 3 part name, ommiting server name.
> "Aaron" <Aaron@.discussions.microsoft.com> wrote in message
> news:EF38347D-6147-407B-A86F-AC0C326AD168@.microsoft.com...
>
>|||Any data modification statements BEGIN an implisit transactions, that is why
selects worked and update fails now. Because it is involving linked server,
it is considered distributed.
BOL
Starting Transactions
You can start transactions in Microsoft SQL ServerT as explicit,
autocommit, or implicit transactions.
Explicit transactions
Explicitly start a transaction by issuing a BEGIN TRANSACTION statement.
Autocommit transactions
This is the default mode for SQL Server. Each individual Transact-SQL
statement is committed when it completes. You do not have to specify any
statements to control transactions.
Implicit transactions
Set implicit transaction mode on through either an API function or the
Transact-SQL SET IMPLICIT_TRANSACTIONS ON statement. The next statement
automatically starts a new transaction. When that transaction is completed,
the next Transact-SQL statement starts a new transaction.
Connection modes are managed at the connection level. If one connection
changes from one transaction mode to another it has no effect on the
transaction modes of any other connection.
"Aaron" <Aaron@.discussions.microsoft.com> wrote in message
news:A8695506-E70A-4412-8417-97E91699C2A0@.microsoft.com...
> Thanks for the advice, however, we have tested it with XACT_ABORT set to
> ON.
> One of our database guru's mentioned:
> --start quote--
> "SQL Server still sees the all the involved statements as a single
> transaction and because it have a call to the linked server, it tries to
> initiates it as distributed transaction."
> I read in the sql server docs that whenever two databases are involved,
> sql
> server treats the transaction as a distributed transaction even if the
> databases are on the same box
> --end quote--
> Example: our stored procedure has a query similar to the following:
> sql1 is the loop back linked server, the database resides ON the same box,
> however, for various reasons we have left the sp to reference it as a
> linked
> server.
> update mytable
> set mytable.column1 = 1
> where NOT EXISTS
> (select id from sql1.dbo.mytable2 p where p.column = mytable.column)
> The following error message is generated whenever the trigger on
> update/insert is active on the table mytable. We remove the trigger and
> the
> SP works as always:
> error msg: The operation could not be performed because the OLE DB
> provider
> 'SQLOLEDB' was unable to begin a distributed transaction.
>
> Thanks for any help you can provide.
>
> "Itzik Ben-Gan" wrote:
>
Distributed Scenario...
Hi ,
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
Soni
I cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegr oups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
Soni
I cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegr oups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>
Distributed Scenario...
Hi ,
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
SoniI cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegroups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
SoniI cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegroups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>
Distributed Scenario...
Hi ,
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
SoniI cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegroups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>
We're building a windows app and using SQL 2005.
The scenario is this.
Our app will be spread across various geographical locations.
The information is more or less location specific i.e. a user in one
loaction will probably not require to see/modify the data in another
location. We are looking at huge volumes of data and the connectivity
could be pretty decent.
Do we
1. Go with one centralised server?
2. Go with a server for each location.
In this scenario what would be the impact on the cost.
3. Go with Point 2 but also have one centralised server which will sink
up data from all locations. Is this suggested? If so does SQL server
have some kind of automatic sync utility or services which can be say
run at a particular time?
4. I do not have much info on Mirroring but will this help if I were to
use a centralised server.?
Thanks in advance
SoniI cant be certain without having some more info regarding size and req for
your scenario. I would probably use option 3 and yes, you can maintain
centralised server through replication or SSIS or some other feature
depending on your needs.
As for the 4) Mirroring will not be available untill mid 2006 and it could
help, again depending on what would you want to do on the centralised
server...
MC
"hangar18" <soni.somarajan@.wipro.com> wrote in message
news:1133250860.462491.247260@.f14g2000cwb.googlegroups.com...
> Hi ,
> We're building a windows app and using SQL 2005.
> The scenario is this.
> Our app will be spread across various geographical locations.
> The information is more or less location specific i.e. a user in one
> loaction will probably not require to see/modify the data in another
> location. We are looking at huge volumes of data and the connectivity
> could be pretty decent.
> Do we
> 1. Go with one centralised server?
> 2. Go with a server for each location.
> In this scenario what would be the impact on the cost.
> 3. Go with Point 2 but also have one centralised server which will sink
> up data from all locations. Is this suggested? If so does SQL server
> have some kind of automatic sync utility or services which can be say
> run at a particular time?
> 4. I do not have much info on Mirroring but will this help if I were to
> use a centralised server.?
> Thanks in advance
> Soni
>
Subscribe to:
Posts (Atom)