Here you go

http://www.devarticles.com/c/a/SQL-Server/Replication-SQL-Server-2000-Part-2/

There is a Part 1 but it is mostly on concepts and theory. This one has a Step By Step.

I tried to set it up with WebHost4Life. But, it is available for an extra $$ a year. However, for semi or dedicated i think it is included. I will do it because it is not easy to backup, FTP, and restore a 100MB sql file for me.

You can replicate Tables, Sprocs and Views, Triggers, Indexes, etc You can also set filters. Filters allow you to replicate say, PortalD = 0 This will exclude other portals in you DNN installation.

Go on, read...and happy replication.

This might not be the best solution in the world but it does work.

(This is going to sound crazy but here goes) Use a Flash Drive.

I put a dnn installation on a flash drive (Note the Drive Letter used). I created the SQL Server DB and Log file on the Flash drive as well.

Enable the Web Share on the Drive and you should be able to open the sln file and run the DNN from Visual Studio (This appears to work best the first time you start up).

Before you disconnect the drive shutdown SQL Server, remove the web share (you might have to restart IIS) and take the drive to the other computer.

Repeat the same process (rename the SQL Server files on the flash drive first) and make sure you use the same Drive Letter for the Flash Drive.

To move the flash drive from one pc to another just stop SQL Server, remove the web Share ( I usually restart IIS) remove the drive. At the other computer once the drive is in, start SQL Server, Add the web share, (I generally restart IIS) and you should be good to go.

Make sure you use the same Drive letter on both computers and the SQL Server files are named the same. I use the same UserName and Password for the SQL Server Connection on both computer as well, otherwise I'd have to change the web.config file too.

The only problem I've seen occurs after the Flash Drive is First plugged in and you attempt to open the DNN home page using a browser (prior to opening the solution). Once the sln is opened and you start the application (from Visual Studio), you can use a browers to open and navigate the site as usual.

Developing on the flash drive is a little slow at times, but I have had no major problems developing modules at home or at work. I do however back up the flash drive just about every day (in either one location or the other).


I realize this solution is a bit eccentric, so don't verbally abuse me to bad.

i have replication working (data getting around) but it doesn worked with dnn.its gives a error

getting error :

A column named 'rowguid' already belongs to this DataTable.


i used a newie so i used common sense and mostly used the defaults. i select all teh tables n stored procedures. the only difference i find in teh http://www.devarticles.com/c/a/SQL-Server/Replication-SQL-Server-2000-Part-2/ is the part on scripts and some identity table. (truly i dont understand this)

any idea where i might be going wrong, its worth a try to use the article

m





mitesh

Because some tables are creating GUIDS, you have to exclude those from the replication process. GUIDS are created based on machine and time information and so they become problematic when you try to replicate them.

Since replicating the whole DB would be stupid (better to create a back up and install it), I think perhaps setting up a publish and subscribe model would solve the issues in this thread.

Of course if you install any modules or any other significant DB events are happening you will have issues!

so how i know which tables are creating GUID and where?

i was just using a basic dnn with sql server in test machines, i dont lose any data. thing is i dont understand how **** others in the forum and other pppl worldwide are managing to do replication and i get error with snap,tran,merge replication.

I was able to set this up a few times and it works well... I have run intot he problem that you describe when i set up replication and it failed. When I tried to set it up again, some of the RowGuid Fields (that are added to the tables by SQL Server Replication) already existed and it caused the setup to choke with similar errors.

I was able to get around this by deleting the RowGuid Fields from the table and letting SQL Server add them again. If you are unsure as to whether the field was added by replication or not, comapre your DB to a clean DNN and see what differences there are.

WARNING: Schema changes will not propogate through replication. If you installa new module that creates tables or upgrade the DNN, you will have to set up Replication again.

so in simple words, i should delete the rowguid column or column data from every table since almost or all the tables in dnn have rowguid column created after replication?????

theory wise, rowguid is my problem: "rowguid already exists in the...." If sql replic gonna pu the guid again would i get back my old error.

doesnt any 1 have more simple ways to do replication. if i have to teach this to my colleagues, first word would be ' huh '.

If $$ are no object I would recommend two pieces of sofware from Red Gate.

SQL Compare

SQL Data Compare.

http://www.red-gate.com/sql/summary.htm

I have only limited experience so far with them but I use these tools to generate the Schema and Data Scripts for the Install procedure.

I have also used them successfully to copy an online site to my laptop (in ~ 20 mins), so I could demo offline. Most of the time incured being the time to download the data. Incremental updates are much quicker, as only the changes are scripted.

The tools give you three options once you have determined the objects to script.

1. Apply them automatically
2. Launch the SQL Query Analyzer (with the script file)
3. Save the script file

Hope this helps.

Hey daniel:

Well, I'd love to find someway that I could just take the changes from my development laptop, both db and dnn folder, automatically replicate to the test server, and then when I feel comfortable, replicate to the 'live' server.

The problem is, on a *live* website, there's this issue of 'users' ;-) So unless I want to delete all new users, what I end up doing is detaching and uploading the database, messing with the user tables (ie. comparing them, and exporting/importing any changes, and upload the new dnn folder.

This is a *really* lousy way of living, my friends. But I can't see another easy and cheap way of doing this that works w/multiple sites. Forget about updating changes nightly...for me anyway. I *wish* I could do this, but it takes about an hour to upload the changes, compare, fix, and reattach, and restart.

This is something that would appear to be a great product to offer, sort of like a 'versioning' of everything except users, or to be more specific, to be able to 'explain' the user associated tables (including custom modules) to this 'versioning' module', and have it automatically version the old info, allow one to manage the versions, so we could 'roll back', but to do this on a portal-wide basis, than on just a module basis...

If wishes were horses....

And BTW, I saw a thread that said that people are having convincing the old folk to convert to DNN. Hey, I'm an 'old folk', and I resent that! ;-) You just have the *wrong* old folk 'running' your IT dept. :)

RedGate is an amazing tool and would really be of use.

>>Because some tables are creating GUIDS, you have to exclude those from the replication process. GUIDS are created based on machine and time information and so they become problematic when you try to replicate them.

Just trying to learn here - Im fairly new to replication, but my understanding is that GUIDs are specifically very good for replication because they are based on machine and time info: it allows systems to generate ids locally instead having to connect to the main database to get ids.

For ex. two servers AAA and BBB replicate up to server SSS

On AAA a user creates two customer records:
GUIDs AAA1... and AAA2....

On BBB a user creates two customer records:
GUIDs BBB1... and BBB2....

All without having to call SSS.

Then when replication kicks in the

Besides the fact that GUIDs are so frickin huge (disk space wasting ;-) ) the only other potential problem I think would be if the key needs to hold some sequential significance, which I think might be handled with a timestamp. Again, not attacking just trying to learn...

Thanks,
Rick

i saw the GUID field is present in portals or modules tables prior to replication. after replication, most (or maybe all) tables get a column called rowguid.

from my understand, rowguid is necessary for replication, it uses guid to identify which out of the 2 tables or rows is the latest. after knowing the latest, it would just then replicate or update the old one. so both tables are up to date.

now the problem (i think) is that will a table, i mentioned above, there will be 2 columns with guid thus it is a problem. now deleteing the guid column wont solve the problem, as it getting created again for replication. there should be a easier or automate the whole process for dnn. the problem could be solved via dnn coding to tell it and can be used for replicated.

m

Dennis, how much does red gate cost? they dont say on the site? which worries me :D

hi guys,

i managed to get one replication working with dnn, it was a merge replication and we didnt send in two tables. TABS and MODULES. the first DNN didnt give a rowguid error but this was not the solution we were looking for. some one might be able to move on from here.

2 sql and 2 iis. sync them. big ? still for me.

M