Advice on a database Replication

Hi,

I.m trying to find the best practice for my solution.

This is the situation.

My application has two databases and 2 client interface. One with a windows forms having a database (sql server 2000) running in an office (on a static IP but on a slow connection). the second one is an web application running on the net with an online database. Both these databases have to have same information. Users can add records to both databases independently but these databases should be synchronize at a point. I hope the situation is cleare. Is there a standard way of doing this. If some one knows good article of how this can be done pls forward it to me.

Many thanks.

-VJ

You can look at Merge Replication, it can handle changes at both ends, as well as handle conflicts if necessary. How many changes per sec or minute do you expect at both ends?|||

Hi Greg,

Yes I was reading on merge replication. there can be about 200 -300 changes on the office side per day. And only about 50 changes from the web side. My only worry is the slow connection from the office end but it can run over night.

By the way whne u have created a replication can reverse it back as I created a replication and I need to change the tables. It's not very easy to do that while having the replication.

Thank you.

-VJ

|||

What is considered a "slow connection", dial-up? With such a small workload, you can schedule your syncs several times a day if you need the changes sooner.

In sql 2000, schema changes can be handled only by sp_addreplcolumn and sp_dropreplcolumn. In sql 2005, this has been expanded to include the actual ALTER TABLE command as well as several other regular TSQL commands.

|||

Hi Greg,

The slow connection is a ISDN and the speed is 64Kbps upload and 128Kbps download. The changes will only be adding and modifications to records and it's all text data. Hope this connection can handle it.

Cheers,

VJ

|||if it's a reliable connection, it should handle it fine. If you expect line drops, then the merge agent retries will cause overall duration to increase.|||

One more quick thing. if the connection drops will the server drops the data or will it rollback and run the synchronization again. This is the first time I'm doing this

Cheers,

-VJ

|||merge agent will retry the data it failed, or retry from its last savepoint.|||I had implemented with more than 10,000 record sync daily on merge replication running on a very bad dsl connection that has frequent bad packet, but it work well, as long as the config. on the replication suit the environments.|||

Hi,

Sounds good. But what exactly did u implied by the config suits the environment,

Thanks,

-VJ

|||U have to config merge agent profile to suit your current environment.For example, the size of the batch to sync and others.sql

Advice on a database Replication

Hi,

I.m trying to find the best practice for my solution.

This is the situation.

My application has two databases and 2 client interface. One with a windows forms having a database (sql server 2000) running in an office (on a static IP but on a slow connection). the second one is an web application running on the net with an online database. Both these databases have to have same information. Users can add records to both databases independently but these databases should be synchronize at a point. I hope the situation is cleare. Is there a standard way of doing this. If some one knows good article of how this can be done pls forward it to me.

Many thanks.

-VJ

You can look at Merge Replication, it can handle changes at both ends, as well as handle conflicts if necessary. How many changes per sec or minute do you expect at both ends?|||

Hi Greg,

Yes I was reading on merge replication. there can be about 200 -300 changes on the office side per day. And only about 50 changes from the web side. My only worry is the slow connection from the office end but it can run over night.

By the way whne u have created a replication can reverse it back as I created a replication and I need to change the tables. It's not very easy to do that while having the replication.

Thank you.

-VJ

|||

What is considered a "slow connection", dial-up? With such a small workload, you can schedule your syncs several times a day if you need the changes sooner.

In sql 2000, schema changes can be handled only by sp_addreplcolumn and sp_dropreplcolumn. In sql 2005, this has been expanded to include the actual ALTER TABLE command as well as several other regular TSQL commands.

|||

Hi Greg,

The slow connection is a ISDN and the speed is 64Kbps upload and 128Kbps download. The changes will only be adding and modifications to records and it's all text data. Hope this connection can handle it.

Cheers,

VJ

|||if it's a reliable connection, it should handle it fine. If you expect line drops, then the merge agent retries will cause overall duration to increase.|||

One more quick thing. if the connection drops will the server drops the data or will it rollback and run the synchronization again. This is the first time I'm doing this

Cheers,

-VJ

|||merge agent will retry the data it failed, or retry from its last savepoint.|||I had implemented with more than 10,000 record sync daily on merge replication running on a very bad dsl connection that has frequent bad packet, but it work well, as long as the config. on the replication suit the environments.|||

Hi,

Sounds good. But what exactly did u implied by the config suits the environment,

Thanks,

-VJ

|||U have to config merge agent profile to suit your current environment.For example, the size of the batch to sync and others.

Adp And Sql Server 2005

We upgraded SQL Server 2000 to 2005 We have Access 2003 as the user interface. We are having issues with permission now and when I go into the ADP to create a function or a Stored Procedure it tells me that "the version of Microsoft Office Access doesnt support design changes with the version of Microsoft SqL Server your access projet is connected to. See the Mircrosoft Office Update Web site for the latest information and downloas (on the Help menu, click office on the Web). your design changes will not be saved".

And then when I get inside the design view, it says CAUTION: NEW DATABASE FEATURES NOT SUPPORTED. "You have connected to a version of SQL Server later than SQL Server 2000. The version of Visual Studio or Access that you are using was released before the version of SQL Server to which you are connected. For this reason, you might encounter problems.

Please check with Microsoft to see if there is a service pack that you should apply to Visual Studio or Office in order to get support for the version of SQL Server to which you are connected.

You can continue but any new object types might not be enumerated, and it will not be possible to save any objects or database diagrams that you create using the Visual Database Tools."

Can anyone help pleasewell have you checked for an access 2003 service pack? that is where i would start. otherwise you might have to abandon the Access 2003 crutch and do your development directly in SQL Server <gasp>.|||Thank you I dont mind going through development directly its just that before I at least had the option available, I use to do both but now looks like I cant.|||You may be running into the issue described at the end of the quote in post 6:

http://www.dbforums.com/showthread.php?t=1620139

ADO.NET problem?

I'm experiencing a strange problem that I believe is related to ADO.NET
but I can't say for sure.

I have a simple ASP.NET reporting interface to a SQL Server 2000
database. One report that we run returns a listing of community
members and their contact information using a stored procedure.
Depending on the selected community, this can return from a hundred to
over 1000 rows. Occasionally, the report stops running when a
community with large membership is run -- the report hangs for a while
and then comes back empty (no dataset). If I try to run the stored
procedure directly with the same parameters, everything seems perfectly
fine. I can temporarily fix the problem by simply running an ALTER
PROCEDURE statement without making a single change to the procedure.
The report will now run fine for several days until it eventually stops
again.

I can't reproduce the problem in my development environment.

Does anyone have any ideas as to what this could be?

Bill E.
Hollywood, FL(billmiami2@.netscape.net) writes:

Quote:

Originally Posted by

I'm experiencing a strange problem that I believe is related to ADO.NET
but I can't say for sure.
>
I have a simple ASP.NET reporting interface to a SQL Server 2000
database. One report that we run returns a listing of community
members and their contact information using a stored procedure.
Depending on the selected community, this can return from a hundred to
over 1000 rows. Occasionally, the report stops running when a
community with large membership is run -- the report hangs for a while
and then comes back empty (no dataset). If I try to run the stored
procedure directly with the same parameters, everything seems perfectly
fine. I can temporarily fix the problem by simply running an ALTER
PROCEDURE statement without making a single change to the procedure.
The report will now run fine for several days until it eventually stops
again.
>
I can't reproduce the problem in my development environment.

It sounds that you run into a command timeout, and the error message
is then thrown away.

I assume that when you run the procedure directly afterwards, that you
are running it from Query Analyzer.

Next time this happens, before you run the procedure in Query Analyzer,
issue this command:

SET ARITHABORT OFF

My prediction is that it will now run as slow as it did ASP .Net.

As you may know SQL Server creates a query plan for a stored procedure
when you run it the first time, and this plan is put into cache.

Now, there can be more than one plan for the same procedure, because
of the different set options. For a discussion on this see
http://www.karaszi.com/SQLServer/in...compile_set.asp.

All modern client APIs uses the same SET options by default. Query
Analyzer uses a different default on one point: it runs with SET
ARITHABORT ON, which a client API does not.

Therefore when you run the procedure from QA, you will get a different
plan than you did for the ASP .Net client.

Next phenomenon is something called "parameter sniffing". When SQL Server
creates the query plan for a stored procedures, it looks at the input
parameter for the first invocation. My guess is that the weh page runs with
a plan that is good for a small selection. Typically there will be no
plan in cache which matches the settings for QA, so you will get a plan
which is better fit for the larger selection.

Note here that this does not say that things will faster if ARITHABORT
is ON. Had the defaults been in the reverse, you would have seen the
same behaviour. (With one qualification: ARITHABORT must be ON for
indexes on computed columns and views to be used, so if such are involved
it can make a lot of difference.)

Exactly what is the best resolution for your situation is difficult to
say with the amount of information given. If you can live with the slow
response time on large selections, set the CommandTimeout on the Connection
object to 0, to prevent timeouts from happenning. (There was a bug in
earlier versions of SqlClient where 0 was interpreted as 0. If you have an
old version of .Net Fx 1.x, you may have to set the command timeout to 32767
instead.)

If that is not feasible you may have to review indexing and also examine
the query plan in more detail.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland,

Thanks for the response as always.

I'll try the SET ARITHABORT OFF in query analyzer the next time it
occurs. I would be very interested to see what happens in this case.

When it's working, the query runs very quickly, even when 1000 rows are
returned. This is true for both query analyzer and the web page. Of
course when it breaks down, the web page stops but query analyzer still
runs it in a split second.

I certainly know that SQL Server creates an execution plan on the first
run, but I never thought that there would be two execution plans and
certainly not a different one for a large resultset vs. a small
resultset.

The query contains a large number of subqueries which I think might be
confusing the optimizer. Perhaps a solution using some temp tables
will help--I'll have to see.

No, setting the timeout longer won't suffice, especially when I know
that the query has the potential to run quickly.

Bill

Erland Sommarskog wrote:

Quote:

Originally Posted by

(billmiami2@.netscape.net) writes:

Quote:

Originally Posted by

I'm experiencing a strange problem that I believe is related to ADO.NET
but I can't say for sure.

I have a simple ASP.NET reporting interface to a SQL Server 2000
database. One report that we run returns a listing of community
members and their contact information using a stored procedure.
Depending on the selected community, this can return from a hundred to
over 1000 rows. Occasionally, the report stops running when a
community with large membership is run -- the report hangs for a while
and then comes back empty (no dataset). If I try to run the stored
procedure directly with the same parameters, everything seems perfectly
fine. I can temporarily fix the problem by simply running an ALTER
PROCEDURE statement without making a single change to the procedure.
The report will now run fine for several days until it eventually stops
again.

I can't reproduce the problem in my development environment.

>
It sounds that you run into a command timeout, and the error message
is then thrown away.
>
I assume that when you run the procedure directly afterwards, that you
are running it from Query Analyzer.
>
Next time this happens, before you run the procedure in Query Analyzer,
issue this command:
>
SET ARITHABORT OFF
>
My prediction is that it will now run as slow as it did ASP .Net.
>
As you may know SQL Server creates a query plan for a stored procedure
when you run it the first time, and this plan is put into cache.
>
Now, there can be more than one plan for the same procedure, because
of the different set options. For a discussion on this see
http://www.karaszi.com/SQLServer/in...compile_set.asp.
>
All modern client APIs uses the same SET options by default. Query
Analyzer uses a different default on one point: it runs with SET
ARITHABORT ON, which a client API does not.
>
Therefore when you run the procedure from QA, you will get a different
plan than you did for the ASP .Net client.
>
Next phenomenon is something called "parameter sniffing". When SQL Server
creates the query plan for a stored procedures, it looks at the input
parameter for the first invocation. My guess is that the weh page runs with
a plan that is good for a small selection. Typically there will be no
plan in cache which matches the settings for QA, so you will get a plan
which is better fit for the larger selection.
>
Note here that this does not say that things will faster if ARITHABORT
is ON. Had the defaults been in the reverse, you would have seen the
same behaviour. (With one qualification: ARITHABORT must be ON for
indexes on computed columns and views to be used, so if such are involved
it can make a lot of difference.)
>
Exactly what is the best resolution for your situation is difficult to
say with the amount of information given. If you can live with the slow
response time on large selections, set the CommandTimeout on the Connection
object to 0, to prevent timeouts from happenning. (There was a bug in
earlier versions of SqlClient where 0 was interpreted as 0. If you have an
old version of .Net Fx 1.x, you may have to set the command timeout to 32767
instead.)
>
If that is not feasible you may have to review indexing and also examine
the query plan in more detail.
>
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

|||(billmiami2@.netscape.net) writes:

Quote:

Originally Posted by

When it's working, the query runs very quickly, even when 1000 rows are
returned. This is true for both query analyzer and the web page. Of
course when it breaks down, the web page stops but query analyzer still
runs it in a split second.
>
I certainly know that SQL Server creates an execution plan on the first
run, but I never thought that there would be two execution plans and
certainly not a different one for a large resultset vs. a small
resultset.

When I said that there could be different plans for large and small result
sets that was a simplification. Consider this simple procedure:

CREATE PROCEDURE get_count @.val int, @.count OUTPUT AS
SELECT @.count = count(DISTINCT col1) FROM tbl WHERE col2 = @.val

Assume that here is a non-clustered index on col2 and that this index
does not include col1, nor is col1 in the clustred index. Assume further
that the distribution of col2 is uneven. 30% of the rows have 0 in this
column, the remaining rows have scattered value.

If the first invocation is for @.val = 10, the optimizer will use the
index to compute the query. But if the first invocation is for @.val = 0,
the optimizer will scan the table, because that is faster in this case.

Now, exactly what is going in your application I don't know. But it
sounds as if the procedure is recompiled at some point, and the input
values at that point are very atypical, leading to a poor execution plan
for regular values. That poor plan could affect smaller selection, but
you could be lucky that the cost is less noticeable in this case.

But why would the procedure be recompiled? There are several reasons
for this. One is change in statistics. By default SQL Server maintains
statistics on the tables, and when they change for a table, referring
procedures will be recompiled. It could also be that the plan falls out
of cache if there is memory pressure, and the procedure has not been
used for a while.

One thing you could consider is to add WITH RECOMPILE to the procedure
definition. In this case the procedure is recompiled each time it is
invoked, and nothing is put into cache. The recompile has a cost, but
at least you prevent a bad plan from sticking.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland,

This occurred again so I immediately tried the SET ARITHABORT OFF
option and you were correct--the query ran slowly in query analyzer as
well.

By the way, we discovered that this problem is occurring not only with
the member listing procedure but also a member search procedure when an
address search option is selected. Other search options do not cause
problems. Therefore, I am beginning to suspect that something is wrong
with our address table. Perhaps we have some fragmentation in an index
or something related. In the interim, I've added the WITH RECOMPILE
clause to these two procedures to ensure that they do not run slowly or
time out. Fortunately, this doesn't appear to be slowing them down
much.

Bill|||(billmiami2@.netscape.net) writes:

Quote:

Originally Posted by

By the way, we discovered that this problem is occurring not only with
the member listing procedure but also a member search procedure when an
address search option is selected. Other search options do not cause
problems. Therefore, I am beginning to suspect that something is wrong
with our address table. Perhaps we have some fragmentation in an index
or something related.

You can examine fragmentation with DBCC SHOWCONTIG. But I would not expect
that to be the problem, since you apparently get different plans.

But statistics may not be current. By default, SQL Server updates statistics
automatically, but for large tables it may not be often enough.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||I'll take a look.

The table isn't large. It only has about 15,000 rows.

Bill

Administering msde

Hi all,
I am totaly new to all this sql server think. I have installed MSDE on Win2K
Server.
How do you administer this think? Is there een interface? I have tried SQL
webadmin.
When I try to open the site with IE I see source code of the file
default.aspx.
Why is this?
Any help would be great.
tnx. in advance
Admir
hi admir,
admir wrote:
> Hi all,
> I am totaly new to all this sql server think. I have installed MSDE
> on Win2K Server.
> How do you administer this think? Is there een interface? I have
> tried SQL webadmin.
> When I try to open the site with IE I see source code of the file
> default.aspx.
> Why is this?
>
personally I do not like WDA very much... but you perhaps can find some
hints at http://www.sqljunkies.com/forums/ ..
if you need a Web based admin you'd probably better invest in myLittleTools
(http://www.mylittletools.net/mla_sql) ... other free and commercial tools
for administering MSDE are listed at
http://www.microsoft.com/sql/msde/partners/default.asp ,
http://www.aspfaq.com/show.asp?id=2442
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply

Admin User Account from Front -end Interface

Hi all,
I would like to create User Account(mean user can admin
user account) from Front-end (using VB 6.0), pls give How
to, sample program or manual how to.
TIAYou can create a new SQL Server login account using sp_addlogin:
EXEC sp_addlogin 'AdminAccount', 'AdminPassword'
Or you can grant an existing windows account access to SQL Server with
sp_grantlogin:
EXEC sp_grantlogin 'MyDomain\AdminAccount'
If the account is to be a server administrator, you can add it to the
sysadmin server role:
EXEC sp_addsrvrolemember 'AdminAccount', 'sysadmin'
or
EXEC sp_addsrvrolemember 'MyDomain\AdminAccount', 'sysadmin'
Note that you shouldn't use a sysadmin login for routine application access.
See the Books Online for more information.
Hope this helps.
Dan Guzman
SQL Server MVP
<thankch@.hotmail.com> wrote in message
news:045b01c3c9c3$6b3384d0$a301280a@.phx.gbl...

quote:

---

> Hi all,
> I would like to create User Account(mean user can admin
> user account) from Front-end (using VB 6.0), pls give How
> to, sample program or manual how to.
> TIA
>

---