Introduction to Geodatabase Replication at ArcGIS 9 2

good afternoon my name is Heather McCracken and I'm with the geo database development team here in Redlands California joining me today is my colleague Jay mcdougal who's also with the Jui database development team we want to welcome you all to today's live training seminar introduction to geo database replication at ArcGIS 92 to begin I'd like to briefly go over the topics that will be covered in today's session I will start by exploring what geo database replication is where I'll talk about some use cases for replication and then discuss the three replica types available secondly I'll cover the replica creation process I'll then move on to talk about replicas synchronization and lastly we'll discuss replica management throughout each topic there will be software demonstrations and at the end of each topic there would be time for a review and QA during development of geo database replication the development team has strived to keep the following goals in focus we wanted to build upon the disconnected editing functionality release that ArcGIS 8 3 we wanted to support more workflows for distributing data and we wanted to include enhancements described by our disconnected editing users such as allowing multiple data synchronizations without having to check out data each time improve support for replicating relationship classes better tools for describing replicas and tools for working with schema changes I will now outline what geo database replication is and what it allows us to do Jui database replication allows us to distribute copies of our data to two or more geodatabases you can edit these jus databases independently and synchronize the changes when needed now let's consider some use cases for replication you may have users need to be disconnected from the network so for example you might have mobile users and field crews that need to be editing data while on-site they'll want to come back into the central database at the end of the day and synchronize their changes another use case may be where there's a need to maintain copies of data at different geographic facilities in this case you can make copies of your corporate data using replication and distribute this to your data distribute your data to your regional offices in some cases users may need to maintain copies of data at different organizational levels a good example of this is in the case of a government structure where each level of government maintains their own data sets and they share their data by synchronizing their changes between their geodatabases some users may want to maintain copies of data in both a production and a publication view database you have a production to your database where all your editors are doing their work and making their changes and once those edits have been qAQ seed they are then sent to the publication geo database it is then used for printing Maps or maybe publishing information on the Internet these are only a few case scenarios but it might give you an idea of how replication can fit into your organization's workflow now let's move on to discuss you database replication in a little more detail the basic replication relationship is between two replicas where the source of the data is the parent replicas and a child is then created from the parent when you create a replica you need to geodatabases you start with one geo database that contains the data and then you replicate to the second in this diagram the top geo database is the origin geo database where all the data exists when the replica is created this database is labeled as the parent replicas the geo database at the bottom is the destination geo database where the data is being replicated to and this gets labeled as being the cha replicas together they're known as a replica pair once the replica has been created you can synchronize the changes between the two replicas geodatabases replicas can be created from a specific version of your geodatabase so you could choose to replicate the default version or any other named version in your geo database you can also choose to replicate specific data sets within your geo database you don't have to replicate your entire geo database and then within each a data set you can specify a subset of features or records that you wish to replicate again you don't have to replicate all features or records in your data sets it's important to note that geo database replication is supported across database management systems for example you can replicate your data from a Jew database that's hosted by a sequel server database to a do database that's hosted by Oracle or db2 the geo databases do not need to be supported by the same DBMS vendor all replication workflows are supported on both local area networks and wide area networks and when we're talking about the local area network or LAN we're talking about connections to your local geodatabases on your network so for example I have our castilla running on my network and I can just connect to it directly through our catalog or you can connect over the LAN where you can use ArcGIS server and geo data web services to access remote geodatabases so say I've got a geo database in Olympia and I want to be able to create a replica from it off-site what you can do is you can create a Geo data web service for the stood at abase and then you can access it remotely via ArcGIS server all the tools and the Wizards that we'll be using in our demonstration today can work equally well with geo data web services just as they do with your local connections now I'd like introduce you to the three replication types first replication type we'll look at is check out check in replication check out check in replication allows you to replicate your data to a geodatabase make edits and then check the changes back into the parent replicas one time once that check-in process is completed you would need to create another check out if you wanted to make additional changes the next replica type is one-way replication with one my replication you could replicate your data to a child geo database and once the replica has been established you can send the changes multiple times however one-way replication supports sending data changes from the parent to the child replicas geo database only and finally we have to wait replication this is similar to one-way replication where you can send your changes as many times as you wish but for two-way replicas the data sheet changes can be sent in either direction so you can make edits on both geodatabases and you can synchronize from the parent to the child or from the child to the parent as needed now let's take a closer look at each replicas type first let's talk about check out check in replication check out check in is equivalent to disconnected editing which was introduced at ArcGIS 83 so some of you will already be familiar with this replication type if you've already used disconnected editing in previous releases all we've done is move it under the heading of geodatabase replication as with all replication types the parent replicas database must be hosted by an arc SD each year database you can then check out your data from your parent to your child your database for child replicas or sorry for check out replicas the child replicas can be hosted in either a personal geodatabase a file geodatabase or any of our arc ste geodatabases once you've checked out your data you can edit the child's your database and when you're finished you can synchronize your changes with the parent this is also called check in any edit conflicts between the geo database edits will be detected on check-in again the one-way replication only supports one synchronization process so once the child that it's have been synched with the parent the child geo database can no longer be used to check in further changes if you want to make additional changes you would need to create a new check out replica our next replica type is one-way replication one-way replication is used in situations where you want to send changes from the parent to the child replicas only for one-way replicas both the parent and the child must be hosted in an arc s2e geodatabase one-way replication supports two model types both full and simple the full model type supports creating replicas with complex data types like geometric networks and topologies and requires that the child data be versioned with a simple model the child replicas data is created as simple types and is not registered as versioned therefore geometric networks or topologies from the source geo database are not created on the destination once a replica has been created data changes can be sent multiple times from the parent replicas to the child replicas in one way replication the child replicas you database is considered read-only so if there are edits on your child geo database that conflict with those on the parents they won't be detected at synchronised time and they will be overwritten on the child to your database a good example use case scenario for one-way replication is a publication geo database example suppose you have a read only publication geo database that's being used to serve data on the Internet data is not being edited in this publication geo database you have a second geo database your production view database where all the edits are taking place you can use one-way replication to periodically synchronize your up from the production to the publication geodatabase the last replica type is to waiver application to a replication is used when you want to synchronize changes from both the parent and the child replica geodatabases for two-way replication both the parent and the child replicas must be hosted in an arc ste geo database to a replication allows data changes to be sent multiple times in either direction so again you can send changes from the parent to the child from the child to the parent or in both directions within the same operation if the same row is edited in both replicas geodatabases it will be detected as a conflict when the replicas are synchronized reconciled policies are provided at synchronization time to define how the conflicts will be processed and we'll take a closer look at this when we discuss replica synchronization okay let's move on to our first software demonstration where I want to show you replication in action let's imagine that we're part of a utilities field crew that's working for the City of Riverside we have already created our two-way replicas from a subset of data that exists on our enterprise to your database and we've replicated this to our field laptop which is running arc ste personal as a result we've been able to take our data out into the field with us make our edits while we're on-site and then imagine that we've come in at the end of the day and we want to synchronize our changes with our enterprise to your database now I'm just going to point out here that for the purposes of this demo both the enterprise and the field geo database are on the same sequel Express database but imagine that your enterprise is actually a full-blown let's say sequel server running Enterprise ste so in order to synchronize you can right click either connection to your field your database or your enterprise and access the distributed geo database tools and click the synchronize changes command but before I go through this wizard with you I want to show you the changes that will be synchronizing first we'll take a look at our enterprise to database while the field workers have been out we have digitized three new building footprints on the enterprise to your database you can see them right here I'll switch over to our field laptop and you can see that those building footprints do not currently exist on our field database but what we do see is some new service lines and and meters that have been added to the field geo database so we want to synchronize the changes so that both edits can be seen in both databases I'm gonna go back to catalog and again look at my synchronize changes wizard this wizard lets me specify the to geo databases that I want to synchronize so I've got my field geo database and my Enterprise geo database and I have a list of replicas that exist between the two I'm going to synchronize rep demo which is my only replica and I'm going to choose to send the changes in both directions next panel allows me to specify some settings about conflicts and this is something we'll talk about when we discuss replica synchronization I'm just going to accept the defaults click finish and you'll see we have a progress dialog here showing us that our data changes are being sent from the parent to the the field geo database and also from the field back to the parent or the enterprise to database let's go back and take a look at our our map documents and I'm just going to refresh my version my connection to the version on my enterprise database and what we're looking for here is the appearance of those secondaries that were added in the field will refresh and you can see that those have come in they now exist as features in our enterprise database likewise let's go to the field jus database I'm gonna refresh and what we're looking for those new building footprints to come in I'll refresh and there they are we've see that's fully synchronized our changes with our enterprise database now let's take some time to review what we've discussed thus far gieux database replication allows us to create copies of our data and synchronize our changes between two or more geodatabases we've talked about some use cases for replication and we've also introduced the three different replication types check out check in one way and two-way replication I'm now going to turn it over to Gary to answer some of your questions that have come in thanks Heather not from Inglewood asks is it possible to replicate nan SDE tables using geo database replication at 19 and the answer is no you need to have your tables registered with the geo database in order and version and have global IDs added for one-way into in replication if you want to have your tables involved in geo database replication we do have some extensibility objects that you can use to do some post-processing so say for example you run the create replica command you can write an application to listen to some events that then go in and the additional additional custom work that you define gary report unis me asks if both databases in a replica pair use direct connects all the replication still work the answer is yes you just need enough to eat connection since students replication is built on top of the geo database the only requirement is that you be able to connect to the geo database so all of those connection options are available done from norcross asks can you replicate from sequel to access the answer is yes for check out chicken replicas for the other types of replicas one-way replication into a replication you need an artist edu databases a geo database on both ends and since access doesn't support that it wouldn't work in that case build from new york asks can you automate the replication process the answer is yes and the way you do that is is by using two your processing tools so you can create a model with some replication to your processing tools and then export those out to Python attach those to the window scheduler and then run them in regular intervals Heather will show a demo of this later on presentation Brian from Houston asks are there performance advantages of one type of replication over the other well the answer this question is yes there are performance advantages and the reason why is because some types of replication require less processing for example to a replication allows you to sync him from both the parent of the child and from the child of the parent however one during replication only allows you to sync from the parent of the child as a result less work is required for us to process the synchronization so we don't have to worry about needing to send back from the child and the parent and therefore in general performance is better when considering the type of replication to use I recommend reading the online Doc's we step you through the different requirements and the advantages and disadvantages of each replica type and from there you can make your decision now I'll hand it back to Heather to continue the presentation thanks Gary now we're going to continue on and take a look at our second topic replica creation our first step in the replica creation process is to choose which replica type or types it will work for your workflow we have discussed the three replica types that are available check out check in one way and two-way replicas before choosing we would recommend that you have a good understanding of the three replica types you may wish to review the detailed documentation on each type before deciding which replica types this pet fit best into your business workflow and suit your user requirements at the end of our presentation we will provide some additional resources that will help you determine which types of replicas will work for you now let's discuss the different tools that we have available to use when creating replicas first we have the create replica wizard this wizard is accessible from the distributed geo database toolbar available in arcmap the wizard supports a range of default and advanced replicate replication options that will allow you to customize the replica you're creating the crate replica wizard is a recommended way to create your replicas because of these advanced options it offers and during our next software demonstration I'll be showing you the crate replica wizard and some of these options the next set of tools available to you are the create replicas and create replicas from server geoprocessing tools you can find these tools by navigating to the data management tools in our toolbox and expanding the distributed geo database toolset you'll also notice that we have geoprocessing tools for other geo database replication tasks such as synchronization geoprocessing tools provide you with the added functionality of being able to automate your replication tasks for example you could build your own custom models or even create scripts that can be run in the windows scheduler our last way to create replicas is through using the arc objects API the arc objects API is available to support writing code to create replicas you can apply complex criteria and extend replica creation you can use our objects to customize any geo database replication task details about each of these tools that we've talked about can be found in the ArcGIS 9 to desktop help online documentation before you create your replica you must ensure that the data meets the following requirements first you must be connected as the user that has right access to the data all the data must be registered as versioned in your artist ee geodatabase and please note the geo database replication requires the full version architecture so the new functionality of versioning your data with the option to move edits to base is not supported with geo database replication again it must be fully versioned for one way into a replication there are two additional requirements to successfully replicate your data you must add global IDs to all of your data sets and we also require that all data is stored in a high-precision spatial reference and all of these tasks can be completed off the context menu of the data sets in our catalog now that our data has met these requirements the next step is to define the data to replicate replica creation determines the data to replicate using two different mechanisms filters and relationship classes there are three types of filters that can be applied during replica creation first we have the spatial filter where a geometry of a defined area can be used to determine the data to replicate so for example if you're replicating in arcmap the spatial filter is determined by the current view extent of the map document or you could use the boundary of a selected graphic second filter type is using selections where the replicated data can be based on selection sets defined for the individual feature classes and tables the last filter type we have is definition queries where any definition queries applied to individual feature classes and tables can determine the data to be replicated if you have more than one of these filters applied the intersection of all of them is used once data has been added to the replica by processing these filters the relationship class logic is applied this logic looks at the rows that are already being replicated based on your filters to see if they're related to any other rows in your geo database if they are these additional rows will also be replicated in my diagram here I have a parcels feature class this parcels feature class is related to the owners one table through a relationship class called r1 and these owners one table is then related to another table owners - through a second relationship class r2 imagine that you have your parcels feature class in your map document you've sumed to the extent that you want to replicate and what we do is we look to see if any of those parcels in your replicas area are related to records in the owners table if they are we replicate those as well we look to see if those records in the owners table are then relay to records and the owners to table and if they are those will get replicated as well okay now it's time to move on to our second demonstration replica creation for this demonstration I want to take you step back and show you how to create the replica that we were using in the first synchronize our sorry in the first demonstration where we were already synchronizing again let's imagine that we're working as part of a utilities field crew working in the city of Riverside we're gonna be working out on-site for a few you few weeks and we want to be able to take our data out onto our field laptop we want to be able to make edits in the field and come in at the end of the day and synchronize our changes with our central database what we're looking at here in our arcmap document is utilities data for the City of Riverside this data is stored on an enterprise ste geo database in our central office this is going to be our parent replica and we're going to create our replicas to our field laptop which is running on personal SD e I'm going to go to a bookmark that I have of the area that I want to replicate and the area that I want to replicate is a particular city block that's defined with this green graphic now if you'll remember from my slides I discussed using a spatial filter to define the data that you want to replicate and that's what I'm going to do I'm gonna select this graphic and use this graphic as the spatial filter for my replicas I'm going to open up the create replica wizard which is on the distributed geo database toolbar and this first panel asked me the type of replica that I'd like to create I'm gonna specify to create a two-way replica because I want to send changes from my field laptop to database to my enterprise I'm going to navigate to my field database because this is the Jui database I want to replicate to and I'm gonna name my replica and I'm just gonna call it rep demo I'm gonna check to show the Advanced Options in this wizard but again we're just gonna keep the defaults but I do want to discuss some of these Advanced Options with you this next panel gives us the opportunity to specify specify a space spatial extent of our replica because we have a graphic selected in the map the default is to use that boundary of the currently selected graphic alternatively you could choose the current display extent the full extent of the data or specify a particular envelope you also have the ability to explicitly exclude or include any of the feature classes and tables in your map you can choose to replicate the features or just schema only and you also have the ability to choose to apply the spatial extent to any of your feature classes this last option is about replicating your related data by default we do process the relationship classes but if you would not like this to happen you can simply uncheck this option our next panel talks about which replicas either the parent or the child will be the initial data sender and this is not something we need to be concerned with when we're working in a connected environment but we'll talk about this in a little more detail when we talk about replicas synchronization I'm just gonna accept the defaults of the child being the initial data center this next panel allows us to specify key configuration keywords for our child care databases and this last panel lets us specify post create replica options we can choose to change the layers in the map document to point to our checked out data on our field laptop and we can also choose to save a map document that also points to this checked out data and this is a great option if you want to keep the symbology that you specified on your enterprise to your database we're just going to keep the defaults and click finish and you'll see our progress dialog showing you what's happening first we extract the schema for the data we're replicating then we're going to extract the data itself will then look for any related objects and lastly we're going to register the replicas with the workspace this is completed and I've already created a map document that points the data on the field laptop I'm just gonna open up this map document now and you'll see so this is looking at the field laptop that only the features that were either completely within this green graphic or the intersected this graphic we replicated so you'll notice the features outside of that graphic we're not replicated another way we can tell that the replica was successfully created is by looking at our replica manager and this is also another utility that's available off the distributed geo database toolbar this utility lists all the replicas in your workspace so for our field laptop we have just the one rep demo which we just created and it lists various properties about it it's a two-way replica and it's a child replica geo database let's go back and take a look at our enterprise database we can open up the replica manager for this as well and see that same replica listed but this time is listed with a roll of type parent okay let's do a quick review we've talked about how you choose your replica types that are gonna work for your organizational workflow we discuss some tools to help you create your replicas we've talked about preparing your data from replication and also the geo database replication use filters and relationship classes to determine the data to replicate I'm now gonna pass it over to Gary to answer some of your questions that have come in throughout the broadcast thanks Heather Tim from Sydney us excuse me it's checkout available with an arcview license and the answer is yes you can well not yes completely you can use check out with an RFP license to edit the check out database in order to create the check out however you need to have a an arc editor or greater license so if you have simple data with an arc editor greater license you can create the check out and once it's checked out you can edit the data with your arc be licensed and say for example in the field then take it back in and check it in when you go to check in again you need that our editor license Michelle from Alameda asks can you do one way replication to several child Ibiza warrants and the answer is yes you can have a single geo database that hosts multiple parent replicas and each of those parent replicas cannot go to a different child geo database ok Michael from Seattle asks can replication be run as an unattended scheduled job for example at night the answer is yes what you can do is you can create a model and then export that model out to a Python script and then have that script attached to your windows scheduler and then set to run whenever you wish to have it run ok Kevin from Sacramento asks can I still use my pre 92 out and check in applications with our GS 92 the answer is yes because we fully support the fully backward support previous applications you can do this we still have the same geoprocessing tools so all your geoprocessing models will work we also have the same art objects API still supported at 92 where things are different is the user interface we've changed the user interface added added more commands and changed some of the commands but all that same functionality is still there 90 there's a help topic that you can read that well outline the different changes and differences and map the 90 functionality for the pre 9 to functionality ok Steve from Portland asks how do I a global IDs to my data well there are several ways that this can be done you can either use a command within our catalog which which allows you to add global IDs at the feature class table and feature data set level and you can also use a geoprocessing tool for adding little IDs ok with that I'll hand things back to Heather to continue with the presentation thanks Gary now that we've gone through creating a replicas let's talk in more detail about replicas synchronization replicas synchronization is a process that allows you to apply your data changes across your replicas to bases replicas can be synchronized in either a single direction or in both directions so recall that check out check in and one-way replicas are single synchronized in a single direction but two ways can be synchronized in either a single or in both directions replica synchronization is based on exchanging messages between the parent and child replicas and it is fault tolerant civilization uses versioning so replication is built on the versioning technology and the synchronization process involves creating hidden system versions replication uses these system versions to determine what data changes to send and what to receive there are two different modes in which you can synchronize your replicas there is connected synchronization and disconnected synchronization with connected synchronization the replicas geodatabases are connected by computer networks through either a local area network or a wide area network so you can connect your geo databases through local connections or you can use ArcGIS server and do data web services to access remote geodatabases being connected can mean that the geo databases are accessible on the network at all times or only intermittently an example of being intermittently connected is a field worker example when you're out in the field you are not connected but when you come back into your office at the end of the day to synchronize you are connected with disconnected synchronization the jus databases are not on the same network at synchronization time in this case updates are synchronized by exchanging messages between the replicas these operations are performed by the end user and done by exporting files from one replicas transferring these files to the other replicas and then imported these next slides will go through some synchronization examples for a to a replica when you synchronize your replicas in a connected environment you can connect to both replicas geodatabases directly and simply which replicate you'd like to synchronize and we saw this in our first demonstration all the required message exchange to complete the synchronization is managed by the system connected synchronization also allows you to choose the direction in which your changes will be sent this diagram here shows sending data changes in both directions within a single operation from the geo database to the right to the geo database on the left and the opposite direction you'll notice that on this diagram I haven't labeled which replica is the parent and which is the child this is because once you establish your two-way replica it really doesn't matter which is the parent or the child they can both equally send data changes to the other okay now that we've talked about how to synchronize in a connected environment let's do the same workflow in a disconnected environment remember for disconnected synchronization the end user is responsible for message exchange so for our illustration here we're showing our data sender sending data changes to our data receiver through using file transfer the data transitive exported to a file this file can be either XML a Delta personal geodatabase or a delta file geodatabase once the file has been exported it can then be transferred to the relative replica and this can be done so you could burn the file to a CD and send it through the post or perhaps send it through email once it's received by the relative replicas it's been imported next the data receiver exports an acknowledgment file which is then transferred in a similar manner to the data sender this acknowledgement message lets the data sender know that its changes were successfully received by the data receiver you can see the the data change direction is the exact same for a disconnected synchronization as it is with our connected synchronization it's just that the message exchange is handled by the user now I'd like to discuss synchronization in conflict detection during synchronization if there are edit conflicts a reconcile policy is used to determine how to handle those conflicts there are three reconcile policies to choose from in favor of the parent where if an edit conflict occurs the Edit from the parent geodatabase are automatically applied next we have in favor of the child where any edits from the child geodatabase are automatically applied if there is conflict and lastly we have our manual reconcile policy where if a conflict occurs the replicas will be marked as in conflict and we allow you to manually go in and resolve those conflicts on a case-by-case basis and you can do this through using our standard conflict resolution dialog that's available with your regular versioning workflows you can manually reconcile and post the synchronisation version with the replica version and once this wreckin post has been applied to the replica version the replicas will no longer be in conflict so again the first two choices in favor of the parent or in favor of the child automatically resolve any conflicts while the third choice is to manually resolve those conflicts in an edit session and it's up to you for however it works best for your workflow replicas synchronization also allows you to specify whether conflicts will be defined by object or by attribute when choosing to define conflicts by action by object conflicts are detected when any edit to the same feature is applied in both replicas geodatabases so for example on the parent geo database I might move a feature and then on the child geo database I may make a change to a non spatial attribute of the same feature so say I changed the name of the object if you define your conflicts by object this will be considered a conflict but you can also choose to define your conflicts by attribute where conflicts are only detected when the same attribute of a feature is edited in both replicas geodatabases let's move on to our next software demonstration where I'll show you replica synchronization now we're looking again at the same replica that we've been working with throughout our demonstrations and since we've created the replicas we've made some more edits and I'm going to edit some features on the enterprise database I'm going to digitize some new building footprints I'm going to save my edits and now let's go over to the field database the field workers have added some meters and some service lines to those original building footprints we received in the first demonstration we'll add some secondaries here and once we're finished we've come back in at the end of the day again and we want to synchronize our changes with our enterprise database and what I've showed you in our first demonstration was using the synchronize changes command which is available also in arcmap but what we want to do is automate our workflow and a great way to do this is using our geoprocessing tools you can find our just geoprocessing tools in the data management tools let's expand this and look at our distributed geo database toolset and here you'll see that we have a whole host of geoprocessing tools for performing your replication tasks like adding global IDs creating your replicas and synchronizing your changes in both the connected and disconnected environment what I've done before this demonstration is I've actually created a model that that synchronizes the data changes between the field and the enterprise database so I'm going to open it up here all I've done is I've added the synchronized changes command to this model and I've specified the parameters that I'm gonna want to use with each synchronization so I specified the two geodatabases that I want to synchronize my enterprise and my field I've specified the replica name and I specified the directions I I want theta changes to go in both directions I've also specified my conflict resolution policy to be in favor of geodatabase one which is our enterprise database and I've also said I want to define my conflicts by object and you can define these parameters however works for you and they these will be saved in your model now what I can do is I can run this model directly from my geoprocessing tools and that's what I'll do right now you can see that our progress dialog is showing us that synchronization is happening and the data changes are occurring so this is great we've just automated our workflow somewhat because we've been able to specify the parameters that we want to use with each synchronization but what we really want to do is automate this completely so that there's no user interaction and this goes to one of the questions that was brought up in the last Q&A session you can export your model to a script which you can then run into window scheduler and the way you do this is click the model menu go to export script and you can see here you can export your model to either a Python script a java script or a VB script once it has been exported you can then just add it to your standard scheduled tasks which come with your your operating system it's just located in your system tools so all I did here was I just added a scheduled task I navigated to my script and I specified that I want this synchronization to happen every night at midnight so it doesn't require any user clicking any buttons all you have to do is come in connect to the network and this synchronization will happen autumn matically without again any user interaction so this is a great way to completely automate your workflow now let's take a look and make sure that our data changes were received we're looking again at this the field laptop and so remember that we digitized some new building footprints on the enterprise and I'm just going to refresh my connection to the version and you'll see that those buildings have now come in to my field do database let's go look at our enterprise and you'll notice that those meters that we added on our enterprise that's what we're looking to come in here I'll just refresh my connection to the version and you'll see that those changes have come in so again the point I want to drive home here that you can manually interact to synchronize your replicas but we do offer the ability to automate your workflows through either using custom tools which we ran here but you can also completely automate this workflow by setting up your script to run in a window scheduler okay review of what we talked about so far we've talked about replicas synchronization in both a connected and a disconnected environment I went through some synchronization examples with you for chewy replicas and we also discussed the three different replicas reconcile policies in favor of the parent favorite the child and the manual reconcile policy and we also talked about defining your conflicts by object or by attribute I'm gonna pass it over to Gary now to answer some more of your questions thanks Heather Jim from Salinas asks can you add feature classes to your replica database after initial creation the answer is yes we have some API is available to add those feature classes to your replica replicas to your replicas once it's been created the feature classes must be simple and this can only end up be done with code Jim from Salinas also asks is related data replicated if a relate is defined in the archive session or only if a relationship class is in place the answer is only if a relationship class is in place relates in arcmap are only relevant to that arcmap session so it has to be a persistent type of relationship like a relationship plots bridge from fort collins asks can you replicate between two databases inside the single oracle instance with GTA's replication we require two separate geodatabases for rap for replica creation so if you can set up your environment such that each database can work Winston's points through the separate artists te instance which would be two separate databases then this should be possible Jason from Halifax asks what if the schemas change in the replicas geodatabases with today's replication we are fault tolerant that means that if things change such as schemas or if the system crashes then we we can recover so we can recover or we just apply what we can so for example say I add a column to my my feature class and then I synchronize changes well it'll only synchronize what it can so if it doesn't have any information for that additional column those changes won't be synchronized another example is if partway through my partway through my synchronization the system crashes what happens well everything is done inside a transaction so if the system crashes nothing gets committed and the databases are rolled back to the previous state so the system gets recovered you can then go and run the process again and it's at the same point you are at when you start it Mary from Los Angeles asks can I use both connected and disconnected synchronization with the same wrap sometimes connected sometimes not the answer is yes synchronizations whether it be connected or not connected will both work so you can sometimes do forget sometimes you disconnected that's fully supported and now I'll hand it back to Heather to continue the presentation thanks Gary finally I'd like to briefly touch on replica management GIS provides tools to help manage your replicas we've got tools for replica description and viewing and also tools for working with schema changes I'll start first with the replica manager and I showed this tool to you briefly in our replica creation demonstration with this utility you can list all the replicas in your geo database you can rename refresh and review all the properties of each replica and you can also choose to interact with this utility so that you only view say replicas with a roll of type parent or maybe just list the check out replicas in your workspace you also have the ability to access what we call a replica log by right-clicking on a particular replica you can bring up this log and it will list all our synchronisation events that have happened for a particular replica this utility is available in both our catalog and in arcmap next we have the create replica footprints command this allows you to export the contents of your replica manager to a future class each feature in the future class represents the spatial extent of a replica in your workspace so the geometry of each feature is a spaceship electro filter that had been defined for the replicas and attributes for the feature class store the information recorded in the replica manager replicas footprints feature class functions as a helpful administrative tool where you can query for information so for example you can find all the replicas waiting to receive messages you can determine if any of your replicas are in conflict or you can query for all the replicas owned by a particular user so it's a great way to see the status of your replicas in your workplace the next tools I want to talk about our tools for working with schema changes over time schemas may change on the replica geodatabases and replication is designed to be tolerant of most of these schema changes exact for example if the field has been dropped let's say on one rep of the geo database the synchronisation will just simply skip that field and complete the rest the data changes successfully but there may be a point in time where you wish to apply schema changes across sérgio databases and ArcGIS provides you tools to do so a synchronization is done in two separate processes first you need to compare your replica schemas to determine the differences and the result of this comparison is a schema changes file the next step is to import these changes to the replica database the schema differences will be listed and you can choose whether or not to apply these schema changes so lastly we've we've talked about tools to help you manage your replicas we talked about the replica manager which again I showed you in the first demonstration we talked about the crate replicas footprints command and we also talked about tools to help you work with schema changes I'm gonna pass it over to Gary one last time to answer some of your questions thanks Heather third from Denver asks do all users have to be logged off the system for replication to work currently that's usually a recommended for the press to do all that it's expected to do and the answer is no when you're synchronizing changes it's like another user on the system performing edits so other users don't have to be logged off the system to do synchronizations associated with replication vary from Denver also asked the rep the reconcile policies refer to parent and children it says only for one a replication or does it apply to two-way the reconcile policies actually only applied to two-way replication and check out check in replication since one way with one-way replication when synchronizations are performed changes are applied directly the records there is no there is no reconcile that happens during the synchronization so it those policies don't apply done from Irvine asks if I'm using disconnected synchronization what happens if one of the messages get lost gets lost and the answer is that all you need to do in that situation is resend your changes again we just need to export and resend the system is designed to detect if the previously sent set of changes have had acknowledgments come back if they haven't it just simply sends them again Matt from San Diego asks what types of schema changes are supported well we don't we do support a limited set of schema changes where you don't support every type of schema change the schema changes that we support include adding and dropping fields adding and dropping domains as well as dropping topologies and geometric networks for a complete list of all the different types of schema that we schema changes that we support I suggest refer to the online help and the final question I'll take from Tonya from Seattle is how does to your database replication work with history well geo database replication is independent of history you can enable history on your replicated data and have an update when synchronizing if the replicas based on the default version one thing to keep in mind is that the dates stored on the replicas receiving the changes correspond to the time of synchronization not the time when the data was archived on the relative replicas and with that I'll hand things back to Heather to finish up thanks Gary it looks like we're out of time but before we go I'd like to point you to a few more resources we have some instructor-led training as well as the arcgis 9 to desktop help which we referred to throughout the seminar we also have our arcgis server 9 to help which can help you understand a little bit more about what our server has to offer and we also have some white papers that are in progress so keep your eyes out for those your comments help us improve our seminars please take a moment to complete our survey just click the give us feedback link to take the survey we hope you've enjoyed today's seminar and on behalf of ESRI i'd like to thank you all for attending

Channel: Mahmoud Abdelrahman

Views: 9,565

Rating: 4.7647057 out of 5

Keywords: Introduction, to, Geodatabase, Replication, at, ArcGIS, 9, 2

Id: _VTgsw8HGug

Length: 54min 40sec (3280 seconds)

Published: Mon May 02 2011