UA80540C2 - Method, system, device, and information carrier for validating remote database updates; method for validating records in a remote database and data transmission over a communication system - Google Patents

Abstract

Embodiments of the present invention provide a method and system for validating remote database updates over a network. A local database (200) record and a remote database record may be compared and exceptions may be generated. Each exception may describe a discrepancy between the remote and local database (200) records. An exception identifier may be associated with each exception, where the exception identifier may be associated with an identifier of the record. An event identifier may be associated with each event in the updated, where the event identifier may be associated with an identifier of the record. The events and exceptions that correspond to the record may be compared to determine whether the update is valid.

Description

Description of the invention

Claim of priority/cross-reference to related applications. 2 This non-prior application claims priority to the prior application (for US Patent Registration No. 60/330,842 dated November 1, 2001), fully incorporated herein by reference, and the prior application (for US Patent Registration Number 60/365,169 dated 19 March 2002), fully incorporated herein by reference.

The present invention relates to computer databases, more specifically, to a method and system for reliable 70 verification of remote database updates.

As databases grow in size and due to their highly distributed structure, it becomes increasingly problematic to ensure identical versions of data across linked databases. If significant changes occur in one database, it may be necessary to update other databases to incorporate these changes as soon as possible. Performing such updates may cause large amounts of 79 update data to be moved frequently to multiple databases. Potentially, such a process can be extremely complex.

This problem is additionally combined with unreliable communication in systems. In this case, data may be lost in transit. This requires a retransmission of the data, and other databases are updated again. Such repetition significantly reduces the efficiency of the system and reduces the area in which the databases contain the most recent data.

Fig. 1 is a structural diagram of the system according to an embodiment of the present invention.

Fig. 2 is a structural diagram of the concentrator system according to an embodiment of the present invention.

Figure 3 illustrates a possible transfer of database updates from a local database to a remote database, according to an embodiment of the present invention.

Fig. 4 illustrates a sending file according to an embodiment of the present invention. with

Fig. 5 illustrates the initialization file of the shipment, according to an embodiment of the present invention. Gee)

Fig is a timing diagram illustrating the formation of a shipment file and a shipment initialization file, according to an embodiment of the present invention.

Fig. 7 is a block diagram of an embodiment of this invention in which local database update files can be created. at

Fig. 8 is a block diagram of an embodiment of this invention in which a remote database can receive its update files from a local database.

Figure 9 is a block diagram of another embodiment of the present invention, in which a remote database can receive update files from a local database and verify their authenticity. Ha")

Fig. 1OA is a block diagram of an embodiment of the present invention in which the authenticity of 30 update files can be checked. co

Fig. 10B is a block diagram of another embodiment of the present invention in which the authenticity of update files can be checked.

Fig. 11 is an illustration of checking the authenticity of the update file, according to an embodiment of this invention. C 50 Embodiments of the present invention provide a method and system for verifying the authenticity of updates from a remote database carried out over a communication network. A record comparison can be made

From" the local database and the remote database record, and exceptions may be generated. Each exception can describe a "difference between remote and local database records. Each exception can be associated with an exception ID, where the exception ID can correspond to a record ID. Each update event can be associated with an event ID, where the event ID

So can match a record ID. To determine whether the update is valid, av | comparing events and exceptions that match the record.

Figure 1 is a block diagram illustrating a system according to an embodiment of the present invention. Basically, the system 100 can contain a large resident database, receive requests for "travel" 20 search through the communication network and provide search answers. For example, system 100 may be a symmetric multiprocessor (MMP) computer, such as an IBM K5Z/b60009M80 or 580 manufactured by IBM (Agtopk, New York), a Zip Epiegrgizetm10000 manufactured by Zip Misgozuvietv (Zapia Ciaga, California) etc. System 100 may also be a multiprocessor personal computer, for example, such as SotradRgoi! iapi mmI 530 (WHICH has two processors Ipie! RepiishtF I, 866MHz), manufactured by the company Nemiek-Raskaga (Raiu Io, California). System 100 may also include

GF) a multiprocessor operating system, for example, such as IVM AIKHFO 41 5y!p Zoiagiz'm 8 Oregayypd Epmigoptepi,

Ge Kei Nas and IMmOhe 6.2, etc. The system 100 can receive through the communication network 124 periodic updates, which can be included in the database in parallel. Embodiments of the present invention can achieve very high database update and search performance by incorporating each update into the database without using database locking or access controls.

In an embodiment, system 100 may include at least one processor 102-1 attached to bus 101. Processor 102-1 may include an internal cache (eg, cache 11, not shown). Between the processor 102-1 and the bus 101, a secondary memory cache 103-1 can be resident (for example, cache 12, cache I 2/1 Z, etc.).

In a preferred embodiment, the system 100 may contain several processors 102-1...102-P connected to b5 of the bus 101. Between several processors 102-1...102-P and the bus 101, several caches 103- 1...103-P of secondary memory (for example, a look-through architecture) or, as another variant, at least one cache 103-1 of secondary memory (for example, an architecture with a history) can be connected to the bus 101 . System 100 may include memory 104, such as a random access memory (RAM), etc., connected to bus 101 for storing information and instructions to be executed by multiple processors 102-1...102 -R.

Memory 104 can store a large database, for example, to convert Internet domain names to Internet addresses, to convert names or phone numbers to network addresses, to provide and update subscriber profile data, to provide and update user presence data, etc. d. In particular, the size of the 7/0 database and the number of conversions per second can be very large. For example, memory 104 may contain at least 64GB of RAM and may contain a domain name database of 500M (ie, 500x1097) records, a subscriber database of 500M records, a mobile phone number database of 450M records, etc.

In a possible 64-bit system architecture, for example, such as a system containing at least one 64-bit reverse byte-order processor 102-1 connected to at least a 64-bit bus 101, and 75 64-bit memory 104, an 8-byte pointer value can be written to a memory address (cell) on an 8-byte boundary (ie, a memory address divisible by eight, or, for example, a CM) using a single continuous operation. Basically, the presence of secondary memory cache 103-1 may simply delay the writing of an 8-byte pointer to memory 104. For example, in one embodiment, secondary memory cache 103-1 may be a look-through cache operating in write-through mode so that a single 8-byte save command can move eight bytes of data from processor 102-1 to memory 104 without interruption and in just two system clock cycles. In another embodiment, secondary memory cache 103-1 may be a look-through cache operating in write-back mode so that an 8-byte pointer may first be written to secondary memory cache 103-1, which then, in more late time, can write an 8-byte pointer to memory 104, for example, when writing to memory 104 a cache line in which the 8-byte pointer is stored (ie, Ha for example, when a specified line is "dumped into memory" cache, or completely secondary memory cache).

Ultimately, from the perspective of processor 102-1, once data is latched by the output pins of processor 102-1, i9) all eight bytes of data are written to memory 104 in one continuous, continuous transfer, which may be delayed by the actions of secondary cache 103-1 memory, if available. From the point of view of processors 102-2... 102-P, as soon as the data is latched by the output pins of processor 102-1, all eight bytes of data are written into memory av! 104 in one constant, continuous transfer, which is indicated by the cache consistency protocol on caches 103-1...103-P of secondary memory, which can delay writing to memory 104, if available. M

However, if an 8-byte pointer value is written to an unaligned memory location 104, such as a memory address that crosses an 8-byte boundary, then all eight bytes of data cannot be transferred from processor 102-1 using a single instruction 8-byte storage. Instead, processor 102-1 may issue two different and separate save commands. For example, if a memory address begins four bytes before the 8-byte s boundary (e.g., 8M-4), then the first save instruction transfers the four high-order bytes to memory 104 (e.g., 8-4), while the second save command transfers the four least significant bytes (for example, 8M) to memory 104.

Importantly, between these two separate save commands, processor 102-1 may receive an interrupt, or processor 102-1 may release control of bus 101 to another system component (eg, processor 70 102-P, etc.). Therefore, the value of the pointer resident in memory 104 will be invalid until 8 seconds before processor 102-1 can complete the second save command. If another component initiates a single, continuous memory read into the given memory location, then an invalid value will be returned, assuming it is valid.

Similarly, a new 4-byte pointer value can be written to a memory address divisible by four (eg, 4M) using a single continuous operation. It should be noted that in the possible (ee) variant described above, a 4-byte pointer value can be written to memory location 8M-4 using a single save command. Of course, if a 4-byte pointer value is written to a cell that crosses the 4-byte boundary, such as 4M-2, then all four bytes of data cannot be transferred from processor axis 102-1 using a single save instruction, and the pointer value, resident in memory 104, may be invalid for some period of time. The system 100 may also include a non-volatile memory device (VRAM) 106, or other static memory devices connected to the bus 101 for storing static information and instructions for the processor 102-1. A storage device 108, such as a magnetic or optical disk, may be attached to the bus 101 to store information and commands. System 100 may also include a display device 110 (e.g., liquid crystal display (LCD)) and input device 112 (e.g., keyboard, mouse, ballpointer, etc.) connected to bus 101. System 100 may include several network

F, interfaces 114-1...114-O, which can transmit and receive electrical, electromagnetic or optical signals, which carry digital data streams, which represent various types of information. In an embodiment, the network interface 114-1 can be connected to the bus 101 and to the local area network of communication of GAM (LM) 122, while the network interface 114-O can be connected to the bus 101 and the global communication network of UMAM (GM) 124.

Several network interfaces 114-1...114-0 may support different network protocols, including, for example, Sidabia E(Pegpay (e.g. IEEE Standard 802.3-2002 issued in 2002), Rireg Spappei! (e.g.

AMZ5I Standard Kh.3230-1994, issued in 1994), etc. Several network computers 120-1...120-M can be connected to LM 122 and GM 124. In one embodiment, LM 122 and GM 124 may be physically separate 65 communication networks, while in another embodiment, LM 122 and GM 124 may be connected through a network gateway or router (not shown for convenience). Alternatively, LM 122 and GM 124 may be the same network.

As mentioned above, the system 100 may provide OM5 (domain name service) resolution services. In the variant implementation, for distinguishing (the process of determining addresses) OMZ, distinguishing services of OM mainly

Can be split between network transport and data retrieval functions. For example, system 100 may be a search engine (SE) for a server optimized for searching data across large data sets, while a plurality of network computers 120-1...120-M may be a plurality of client protocol engines (PE) , optimized for communication and transportation network processing. | The SHE can be a powerful multiprocessor server that stores the entire OM5 record set in memory 104 to facilitate high-speed 7/0 high-performance searching and updating. In another embodiment, OM resolution services may be provided by a plurality of powerful multiprocessor servers, or a plurality of IESs, each of which stores a subset of the entire OM record set in memory to facilitate high-speed, high-performance retrieval and updating.

In contrast, the plurality of REs may be conventional highly specialized devices based on PCs that /5 Run an efficient multitasking operating system (eg, Kea Nai MOX 6.2) that minimize the transport processing load of the communication network by | SHE to maximize available resources for discrimination

OHM. PE devices can process the nuances of the OM5 protocol of the main communication line, respond to invalid requests

RMZ and multiplex valid OMZ requests to (SOE via LM 122. In another embodiment containing a plurality of OEs that store subsets of OM5 records, REs can determine which device | OE should 2o receive each valid OM5 request and multiplex valid OM requests in the corresponding IES. The number of PEs for one (ESE can be determined, for example, by the number of OM requests that must be processed per second, and the operating characteristics of a specific system. Other indicators can also be used to determine compliance ratios and modes.

In general, other high-volume implementations based on Queries may be supported, including, for example, telephone number resolution, 557 signaling processing, determination to match a telephone number to a subscriber, determination of subscriber location and presence, and ) etc.

In an embodiment, the central server 140-1 of operational transaction processing (OIT TR) can be connected to the GM 124 and receive from various sources applications, changes and deletions (ie, update traffic) for the database 142-1. ОИ TR server 140-1 can transmit updates through GM 124 to system 100, which contains a local copy of database 142-1. ОИ TR server 140-1 can be optimized to process update traffic in - various formats and protocols, including, for example, Hypertext File Transfer Protocol (HTTP),

Recording Recorder Protocol (RCP), Extended Initialization Protocol (ERP), Management System

Services/Mechanized Common Interface (MO) 800, and other operational initialization protocols. The totality of

A read-only IOE can be deployed in a hub-and-spoke architecture (a line running from the co-center to the periphery) to provide high-speed search capabilities accompanied by voluminous incremental updates from the 140-1 server's OI TR.

In an alternative embodiment, the data can be distributed over several OITR servers 140-1...140-5, each of which can be connected to the GM 124. OI TR servers 140-1...140-5 can receive from different sources additions, changes, and deletions (ie, update traffic) for the databases corresponding to them, from p 142-1...142-5 (not shown for convenience). The TR servers 140-1...140-5 can transmit updates through the GM 124 to the system 100, which can contain copies of the databases 142-1...142-5, other dynamically created data, and etc. For example, in an embodiment for geolocation, the TR servers 140-1...140-5 can receive update traffic from groups of remote sensors. In another alternative embodiment, a plurality of network computers 120-1...120-M can also receive through GM 124 or LM 122 applications, changes and deletions (ie,

Go! update traffic) from various sources. In this embodiment, a plurality of network computers 120-1...120-M may transmit updates as well as requests to the system 100. o In an embodiment, system 100 may include a remote database (for example, remote database c 210). For example, new information or 5-year update traffic can be received from the TR server 140-1 through GM 124. In an embodiment, the new information may contain changes to at least one element that already exists in the remote database. The system 100, based on new information received via the communication network, can o create a new element of the remote database, and without restricting access to the remote database for searching, write a pointer to the new element in the remote database using a single continuous operation, e.g. , such as a save instruction. In an embodiment, the processor 102-1 may have a word size of at least n bytes, the memory 104 may have a bit size of at least n bytes, and the save instruction may write n bytes to a remote memory address, placed on the n-byte boundary. In another embodiment (F), the system 100 may physically delete from the memory 104 the existing element corresponding to the new element after writing a pointer to the remote database.

In an embodiment of UOM5 discrimination, each RE (for example, each of several network computers in 120-1...120-M) can combine, or multiplex, several OM5 request messages received through a global communication network (for example, GM 124), into a single Request SuperPacket and transmit the Request SuperPacket through a local communication network (for example, LM 122) to the SHE (for example, system 100). | The UE can combine, or multiplex, several responses to UOM5 request messages into a single SuperPacket of Responses and transmit the SuperPacket of Responses through the local communication network to the corresponding PE. Basically, the maximum 65 size of a Reply or Request SuperPacket can be limited by the maximum transmission unit (MT) of the physical network layer (for example, Sidabia E(Pegpe). For example, the standard sizes of the OM5 request and response message, which do not exceed 100 bytes and 200 bytes, respectively, allow multiplexing more than 30 requests into a single Request SuperPacket, as well as multiplexing more than 15 responses into a single

SuperPacket of Answers. However, a smaller number of requests (for example, 20 requests) can be included in a single SuperPacket of a Request in order to avoid overflowing the MTI (for example, 10 responses) when forming a response.

For larger MTs, the number of multiplexed requests and responses can be increased, respectively.

Each multitasking PE can have an input stream and an output stream to handle p requests and responses, respectively. For example, the input stream can demarshal (unpack) the components of the OM5 request from the input; packets of UOM5 requests received through the global communication network, and multiplex several 7/o Millisecond requests into a single Request SuperPacket. The incoming stream can then transmit the Request SuperPacket over the LAN to | SHE. In contrast, the source stream can receive a SuperPacket of Responses from the IO, demultiplex the responses contained therein, and marshal (package into a standard format) the various fields into a valid OM response, which can then be transmitted over a global communications network. Basically, as mentioned above, other high-volume implementation options based on requests can be supported.

In an embodiment, the Request SuperPacket may also contain status information corresponding to each OM5 request, such as source address, protocol type, etc. | The OE can include information about the status and corresponding answers of the OM in the SuperPacket of Answers. Each RE can then form and return valid OM5 response messages using the information transmitted from (SHE. Therefore, each RE can preferably function as a device that does not change its state during execution, i.e., valid OM5 responses can be formed from information contained in the Answer SuperPacket. Basically, (SHE can return

SuperPacket Responses in the RE from which the incoming SuperPacket originated, however, other possible options are obvious.

In an alternative embodiment, each RE may maintain state information corresponding to each OM request and include a reference, or descriptor, to the state information in the Request SuperPacket. And the OEE may include in the Answers SuperPacket a link to information about the status and corresponding answers of the OM. Each RE can then form and return valid OM5 response messages using the state information links transmitted from the ESR as well as state information supported by it. In this version i) implementation | The SHE can return the Reply SuperPacket to the RE from which the incoming SuperPacket originated.

Figure 2 shows a structural diagram of the architecture of the hub and spokes (star-shaped topology) according to an embodiment of the present invention. Basically, the system may include a local database 200 (which may be located in the central OGTR hub 140) and one or more remote databases 210 (which may be located in the IES devices 100) connected to the local database 200 using any connection mechanism, for example, the Internet or LM 122. Databases can transmit and receive update data.

According to Fig. 3, in embodiments of the present invention, the local database 200 transmits to the remote database 210 P files 300-1...300-E of the shipment and the initialization file 310 of the shipment to update the remote database 210. The update files can be transmitted individually or in batches, such as multiple 300 send files, one 300 send file and one 310 send initialization file, multiple 300 send files and one 310 send initialization file, a single 300 send file, or a single 310 send initialization file. "

In an embodiment of the present invention, the processor 104 can receive from the local database 200 the file 300 pt") of the shipment and/or the initialization file 310 of the shipment containing update data. The system 150 can receive the file

Z00 sending and initialization file 310 sending in the remote database 210 through the communication interface 118. ;" The processor 104 can then compare the update data in the dispatch file 300 or the dispatch initialization file 310 with the corresponding data in the remote database 210. If the data in the remote database 210 is different, then the processor 104 can apply the dispatch file 300 or the dispatch initialization file 310 to the remote base

Go! data 210. Accordingly, the remote database 210 can subsequently be updated with data corresponding to the update data in the local database 200. o Fig.A4 illustrates the file 300 of the shipment, according to an embodiment of the present invention. The fields of the file 300 s may include, for example, the identifier 400 of the file, the time 402 of the formation of the file, the number 404 of transactions M in the file, the full size 406 of the file, the checksum 408, or any similar indicator of control of errors and transactions 410-1. ..410-M (containing transaction identifiers). The indicated fields of the sending file are possible variants intended to illustrate, but not to limit the context of the embodiments of the present invention. Any field that may be useful may be included in the send file 300 .

The sending file 300 contains the changes in the local database 200 between the two points in time. These changes may include, for example, adding new identifiers (ie, data record identifiers), deleting existing identifiers, changing one or more data records corresponding to the identifier,

F) renaming the identifier, empty command, etc. One or more of these changes can be made sequentially and can be called transactions. The shipment file 300 may contain unique identifiers of the transaction data. Transactions may be recorded in the dispatch file in the order in which they are committed in the local database 200. Additionally, for transactions containing more than one change, the changes may be committed within the transaction in the order in which they are committed in the local database 200 database 200.

Basically, transaction identifiers can be randomly assigned to transactions. That is, transaction identifiers do not necessarily grow monotonically over time. For example, two consecutive transactions b5 may have transaction identifiers 10004 and the next one 10002. Accordingly, the order of execution of a transaction can be determined by its placement in the current file 300-E or its placement in the previous file 300-(E-1). Basically, for a remote database update to be fully completed using a single push file, transactions cannot span adjacent files 300. This prevents the update from being interrupted due to network latency, which could result in erroneous data in the remote database 210.

Fig.5 illustrates the initialization file 310 of the shipment, according to an embodiment of the present invention. Fields of the send initialization file 310 may include, for example, a file identifier 500 , a file creation time 502 , a number 504 of M transactions in the file, a full file size 506 , a checksum 508 or any similar error control indicator, and a copy 516 (data) full local database. The initialization file 310 of the shipment may additionally contain field 510, which is the identifier 400 of the file of the last file 70 300 of the shipment, formed before the formation of the file 310, and field 512, which is the identifier of the last transaction fixed in the local database 200 before the formation of the initialization file 310 of the shipment. Data in the local and remote databases 200, 210 can be distributed across tables resident in the databases 200, 210. The databases 200, 210 can support any number of tables. Thus, when the database has tables, the initialization file 310 of the shipment may contain, for each table, a field that indicates the number of entries made to the table. For example, a domain name database might contain a table of domains and a table of domain name servers. Therefore, the send initialization file may contain a field that indicates the number of entries in the domain table and a field that indicates the number of entries in the domain name server table. The field can specify, for example, the name of the table, the key used to index the records in the table, and the number of records in the table. Additionally, the initialization file 310 of the shipment may include a field that indicates the version of the initialization file

From 10 shipments, of course 1.0. The indicated fields of the send initialization file are possible variants intended to illustrate, but not limit, the context of the embodiments of the present invention. Any field that may be useful may be included in the initialization file 310 of the shipment.

As indicated above, the initialization file 310 of the shipment may contain, for example, a copy of the complete local database 200, unified by reading the data. The initialization file 310 of the shipment can become unified with the local database 200 at a time between iv and E, where iz is the start time of the formation of the initialization file 310 of the shipment, and it is the time of completion of the formation. In fact, the only operation that can appear in the file i) initialization 310 of sending is the "adding" operation. That is, when creating the file of initialization 310 of sending, copies of the complete local database 200 at the moment of its time can be written into it. Therefore, an "add" operation can be performed to write the local database 200 to the initialization file 310 of the shipment. IDs about zo Can be written to the initialization file 310 of the shipment in a random order. Alternatively, in the presence of external identifiers, the referenced data records may be written to the referenced data record. yu

The addition of fields 510 and 512 can provide the initialization file 310 of the shipment with some information about the files 300 of the shipment that can be generated and transferred to the remote database 210 during the generation of the initialization file 310 of the shipment. However, the formation of the file 300 of the shipment and the formation of the initialization file 310 of the shipment may not be related to each other due to the lack of dependence between them during formation. Such a structure and process can prevent a less efficient approach in which the generation and application of the dispatch file may be terminated before the completion of the formation of the dispatch initialization file. When continuing the formation and application of the shipment files 300 during the formation of the shipment initialization file 310, as in the embodiment of the present invention, a strict error control of the shipment files З00 can be carried out, and also restrictions on the remote database 210, for example, can be made restrictions on uniqueness or restrictions on external identifiers. The imposition of restrictions can protect the integrity;" data in the remote database 210 by rejecting transactions that violate the relational model of the remote database 210. For example, a constraint on uniqueness may prevent the same key from being stored repeatedly in the database 210.

Go! Fig. b6 presents a timing diagram illustrating the formation of a sending file and a sending initialization file, according to an embodiment of the present invention. According to Fig. b, files 300 of sending (from 81-1 to 8-21) are formed at regular time intervals. In an alternative embodiment, the files 300 send with may be generated at irregular time intervals. In the general case, the formation of the sending file 5o does not occupy the time interval completely. For example, if the files are generated in 5-minute time intervals, then it does not take all of 5 minutes to complete the file generation. In addition, if changes are made in the local database 200 o during the formation of the file Z00 of the shipment, then these changes will be collected in the next file 300 of the shipment. For example, if the generation of shipment file 1-4 starts at 12:05:00 and ends at 12:05:02, then any changes to local database 200 made between 12:05:00 and 12:05:02 are collected in the file sending dv 8-5 (for example, З00-5), which covers the time interval from 12:05:00 to 12:10:00.

Fig. 1 illustrates the 300-5 and 300-19 shipment files. In the specified files, among other fields, are depicted

F) identifier 601 of the file (51-5, 8i-19), time 603 of file formation, and identifiers 605 of transactions (for example, ka 10002). It should be noted that transaction identifiers may not be monotonically ordered. As mentioned above, transaction identifiers can have arbitrary values. However, directly relevant transactions are recorded in the file 300 of the shipment in the order in which they are carried out in the local database 200.

Since the formation of the initialization file 310 of the shipment and the formation of the file 300 of the shipment may not be related, the initialization file 310 of the shipment may be formed at any time. For example, the initialization file 310 of the shipment may be formed before, during, or after the formation of the file 300 of the shipment. Fig. b illustrates the initialization file 310 of the shipment, which is formed in the time interval between the formation of the fourth and fifth 65 files of the shipment (for example, 1-4 and 8-5).

In an embodiment, the send initialization file 310 may include, among other fields, a file identifier (iv-I) 610 , a file identifier 615 for the last send file generated before the send initialization file was generated, and a transaction identifier 620 for the last transaction completed before the file was generated sending initialization. In this possible embodiment, the last generated shipment file is shipment file 5/-4, and the last completed transaction is transaction 10001. The generation of the initialization file 310 of shipment begins 611 at 12:07:29. When the generation of the shipment initialization file 310 begins, the first half of the transactions in the shipment file 300-5 (1-5), transactions 10002, 10005, and 10001 have already been completed in the local database 200. Accordingly, the shipment initialization file 310 may have information about these transactions and may collect these transactions in the send initialization file 310 . However, the initialization file 310 7/0 of the Dispatch cannot have information about subsequent transactions 10003 and 10004 that are carried out after the initialization file of the shipment begins.

When forming the initialization file 310 of the shipment, the files of the shipment, starting with the file 300-5 of the shipment, may continue to be formed at regular time intervals. These files can be transferred to the remote database 210 and applied.

The formation of the initialization file 310 of the shipment can be completed at 1:15:29, in the time interval between the formation of the 18th and 19th files Z00 of the shipment (51-18 and 81-19), it cannot affect the formation of the 19th file 300-19 dispatches.

After receiving and loading in the remote database 210 the initialization file 310 of the shipment, the remote database 210 may not take into account the shipment files formed before the formation of the initialization file 310 2o Shipments. This is possible, for example, due to the fact that the initialization file 310 of the shipment contains all changes in the local database 200 that were written to the previous files 300 of the shipment. In this possible embodiment, the remote database 210 may not need to consider the first through fourth shipment files (51-1 through 8-4). The changes recorded in these shipment files 5-1 to 51-4 may also be recorded in the shipment initialization file 310. The specified previous sending files (from 51-1 to 51-4) can be deleted or, in another version, archived.

Similarly, the remote database 210 may not consider transactions completed prior to the formation of the file i) the initialization 310 of the shipment, which were included in the file 300 of the shipment formed subsequently. Transaction data may be included in the initialization file 310 of the shipment when it is generated. For example, therefore, the remote database 210 may not need to consider the first three transactions 10002, 10005, 10001 from the send file v1/-5. Transaction data recorded in the sending file z51-5 can also be written in the initialization file 310 of sending. These completed transactions may be deleted, or alternatively, archived. -

Figure 7 shows a block diagram of an embodiment of the present invention, in which local database update files can be created. The system may generate (705) several periodic updates based on additional changes in the local database. Each update can contain one or more transactions. The system may then transmit (710) periodic updates to the remote database. When generating periodic updates, the system may start generating (715) initialization updates at startup time.

The initialization update may contain a version of the full local database. The system may determine (720) the last periodic update generated prior to the trigger time and the last transaction completed prior to the trigger time. The system may then transmit (725) the initialization update to the remote database. An initialization update may contain an update ID corresponding to the last generated periodic update and a transaction ID corresponding to the last completed transaction.

For example, the OI TR 140 can form (705) files 300 of sending with some regular or irregular;" time interval. The OI TR 140 can then transfer (710) the shipment files 300 to the remote database 210. When generating the shipment files Z00, the OI TR 140 can begin generating (715) the initialization file 310 of the shipment in

Start time point 611. The initialization file 310 sent may contain a copy of the complete local database 200.

Go! The OGTR 140 can then determine (720) the last send file Z00 generated before the start time 611 to generate the send initialization file 310 and the last transaction completed before the start time 611 to generate the send initialization file 310 . Then the OI TR 140 can transfer (725) the initialization file 310 of the shipment to the remote database 210. The initialization file 310 of the shipment can contain the identifier 615 of the file of Shipment corresponding to the last generated file 300 of the shipment, and the identifier of the transaction 620, which corresponds to the last completed transaction . Figure 8 shows a block diagram of an embodiment of the present invention in which a remote database can receive update files from a local database. The system may receive (805) several periodic updates. Each update can contain one or more transactions. Periodic updates can be received individually or in packages. At some point in time, the system may receive (810) an initialization update.

The initialization update may contain a version of the full local database. The system can read (815) from

F) initialization update identifier of the last periodic update and identifier of the last transaction. The system can then determine (820) the last periodic update corresponding to the update ID and the last transaction corresponding to the transaction ID. A periodic update and a transaction can be, respectively, the last generated update and the last completed transaction before the initialization update is generated. The system may apply (825) to the remote database the pending transactions remaining in the corresponding periodic update. The system may then apply (830) to the remote database the remaining periodic updates generated since the last periodic update. Applying an initialization update will preferably fill in any previously missed periodic updates. 65 For example, the SHE 100 may receive (805) files 300 sent at some regular or irregular time interval. 300 shipment files can be received individually or in packages. At some point in time AND OE

100 may receive (810) the initialization file 310 of the shipment. (The ESR 100 can read (815) from the initialization file 310 the sending file identifier 615 and the identifier 620 of the transaction. The | CE 100 can then determine (820) the sending file 300 corresponding to the identifier 615 of the sending file and the transaction 605 corresponding to the identifier 620 transaction The send file and the transaction may be, respectively, the last generated send file and the last completed transaction prior to the generation of the send initialization file 310. The SOE 100 may apply (825) to the remote database 210 the remaining incomplete transactions 605 in the corresponding send file Z00 Then, the CE 100 can apply (830) the files to the remote database 210

Z00 remaining shipments that follow the last shipment file zvi-4. 70 In an alternative embodiment, for example, (SHE 100 may discard or archive send files 300 that have not been applied to the remote database 210 and/or have a generation time 603 prior to the generation time 611 of the send initialization file. Discarded or archived send files 300 may include the shipment file 51-4 corresponding to the identifier 61 and the shipment file.

It is understood that after the application of the initialization file 310 of the shipment, any later files 300 of the shipment that may have already been applied to the remote database 210 may not be preserved, because the remote database 210 may become read-unified with the initialization file 310 of the shipment.

Accordingly, these later shipment files 300 can be reused.

In an embodiment of the present invention, the send files 300 and the initialization file 310 of the send can be transferred from the local database 200 to the remote database 210 without a message (about the successful receipt of the data, that is, without an ASK/MASK signal to indicate that the files were successfully received This mainly reduces the additional service signaling that the ASK/MASK signal can create.

In an alternative embodiment, an ASK/MASK signal may be transmitted from the remote database 210 to indicate that the files have been successfully received. In this embodiment, the ASK/MASK signal can be transmitted in systems with unreliable communication. with

Figure 9 shows a block diagram of another variant of the implementation of this invention, in which the system can check the authenticity of the update files transferred from the local wild database and received in the remote database (8). Here, the system may transmit (905) a plurality of periodic updates. Each update can contain one or more transactions. Periodic updates can be delivered individually or in batches. At some point in time, the system may transmit (910) an initialization update and apply the initialization update to the remote database. The initialization update may contain a version of the full local database. Initially, the system, using database comparison, can identify (915) differences between the local and remote databases. The system may determine (920) whether the variances are valid or false. The system may then apply (925) periodic updates to the remote database, in accordance with an embodiment of the present invention. This version of the implementation, preferably, can ensure the absence of errors in the remote database, which is the result of receiving updates from the local database. co

For example, ОИ ТР 140 may transfer (905) to the remote database 210 the files 300 of the shipment with some regular or irregular time interval. 300 shipment files can be sent individually or in batches. At some point in time, the UE TR 140 may transmit (910) the initialization file 310 of the send to the GE 100, and the UE 100 may apply the initialization file 310 of the send to the remote database 210. The UE TR 140 may compare the "local database 200 with the remote database 210 and identify (915) differences between them. Then pt") with OGTR 140 can determine (920) whether the variances are valid or false. The OITR 143 may then inform the SHE 100 to apply (925) to the remote database 210 of the shipment files 300, in accordance with an embodiment of the present invention. The ESR 100 can then apply the send files 300 to the remote database 210.

In an alternative embodiment, the system may use the send files and the initialization file

Go! sent for identification and verification of the authenticity of discrepancies. As another option, the system can use the shipment files and the shipment initialization file after identifying and verifying the authenticity of discrepancies. c It is clear that the authentication process can be performed on any data transmitted from the source to the addressee through the communication network to apply the transmitted data to the addressee. ve On Fig. 10A is a block diagram of an implementation option for verifying the authenticity of the shipment file and the shipment initialization file, according to the present invention. After sending several periodic updates and initialization updates to the remote database, the system can verify the validity of these updates. Each update can contain one or more transactions committed in the local database. Each 5B transaction can contain one or more events. An event is an action or possible execution in a database, such as adding, changing, deleting, etc., with respect to data in the database.

F) First, the system can compare (1000) records in the remote database with the corresponding record in the local database. The system may generate (1005) an exception describing the discrepancy between the records of the remote and local databases, and the exception may be generated for each discrepancy. A difference can be any difference, at least in one data value, between two versions of the same record.

For example, there may be a data entry in the local database (12345, khug.sot, 123.234.345). The corresponding data record in the remote database, which is supposed to be identical, can match (12345, ars.sot, 123.234.345).

Accordingly, there is a discrepancy in the second value of the record data. Therefore, an embodiment of the present invention may form an exception that describes the specified difference. An exception can describe a difference, simply 65 Indicating that there is a difference; determining the location of the divergence; describing the difference between two data values when diverging, etc. A record of data in the local database corresponds to a record of data in the remote database (and vice versa) if the two records necessarily contain identical data.

It is understood that a discrepancy may refer to a difference in one or more data values in a record or to a record in general.

The system may assign, (1010) to each exception an exception identifier, and the exception identifier may correspond to a record identifier. For example, a data record (12345, hul.sot, 123.234.345) might have an identifier of 410. Accordingly, an exception identifier might also be 410. Each exception can be classified as belonging to any of several types of exceptions (or discrepancies) . An exception list may be generated to include the exception types and exception ID for the 7/0 exceptions grouped there. The list of exclusions and the different types of exclusions are detailed below. The system may also assign (1015) to each event in the update an event ID, where the event ID may correspond to a record ID. For example, the data record (12345, hul.sot, 123.234.345) can have the identifier 410. Accordingly, the event identifier can also be a10. Each event in the update can be discovered from the event history. The background of events can be a listing, etc. events performed on local database records over a period of time. The background of the events is detailed below.

The system can then determine (1020) whether the record update is valid. Fig. 10B8 shows a block diagram of a variant of the implementation of the determination of the authenticity check. This definition can be made as follows. A comparison (1022) of each event with each exception may be made. If each exception is confirmed (1024) by an event, then the update can be determined (1026) as valid and the given update can be applied to the remote database. Otherwise, if each exception is not acknowledged (1024) by an event, then the update may be determined (1028) to be invalid and the exceptions may be logged as errors. An exception may be confirmed when the exception identifier matches the event identifier and the corresponding event corresponds to a valid sequence of events corresponding to the exception type. Valid sequences are detailed below. If the exclusion is confirmed, the system can remove the exclusion ID from the list of exclusions. A confirmed exception may indicate that the discrepancy is valid, for example, the remote database has not yet received an update, but it will when an update is received. match the local database.

During validation, the system can identify hidden errors or failures in periodic updates and initialization updates. The system can provide the possibility of structural and semantic "correctness of update data, the possibility of successful application of update data that does not cause the formation of exceptions or other unwanted stops, the possibility of visual detection of errors at comparison of local and remote databases with each other, and the impossibility of accidental deletion of significant data. The system can provide the ability to successfully apply periodic updates and initialization updates to a remote database. -

Preferably, validation can detect many errors that occur when attempting to apply an update to a remote database. For example, when you try to apply, you may encounter data centralization errors, warnings that the object already exists in the remote database, or warnings that there is an external identifier violation. Therefore, after performing a validation process in accordance with an embodiment of the present invention, the system may attempt to apply "specified updates to the remote database." The attempt may fail, which may indicate the presence of additional bugs in the update that make the update unreliable. Accordingly, additional attempts and application of the specified updates to the remote database cannot be made. "" In an alternative implementation, an attempt may be made to apply at least one of the updates before performing the validation. If the attempt is unsuccessful, the validation may be skipped and the update rejected. Alternatively, if the attempt is successful, then a validation check can be performed and the valid update is saved, and discrepancies are logged for the invalid update.

In a possible variant of the implementation of the OI TR 140 can verify the authenticity of the sending files З00 and the sending initialization files 310 to ensure the successful application of the sending files 300 and the sending initialization files 310 to the remote database 210.

In alternative embodiments, authentication can be performed by network computers 121, t and OE 100, or any combination of existing systems. o In accordance with Fig. 10A, OI TR 140 can compare the local database 200 and the remote database 210 to determine any exceptions (or discrepancies) between them. Exceptions may include three types: the remote database 210 may contain data that is not present in the local database 200; the local database 200 may contain data that is not present in the remote database 210; or corresponding data may exist in both the local database 200 and the remote database 210, but the data may be different. Of course, the relevant data may exist both in the local database 200 and in the remote database 210, and the data may be identical, in which case the data may be considered valid, therefore, no additional processing is required from the ОИ ТР 140. It is understood that a discrepancy may refer to one or more data values in a record or to a record as a whole.

Accordingly, the OI TR 140 may compare (1000) the corresponding entries in the local database 200 and the remote database 210. The OI TR 140 may generate (1005) an exception that describes the discrepancy between the entry in the remote database 210 and the entry in the local database 200, and an exception can be formed for 65 of each difference. OSI TR 140 may assign (1010) to each exception an exception identifier, and the exception identifier may correspond to a record identifier. An exception list may be generated to include the exception types and the exception identifier for the exception belonging to the exception type. In an embodiment, an exception may be defined as a "List 1" exception (or difference) if the exception belongs to the first type of exceptions, a "List 2" exception if the exception belongs to the second type of exceptions, or a "List 3" exception if the exception does not belong to the third type of exceptions. Fig. 11 illustrates a possible list of 1140 exceptions.

It is understood that the presence of an exception ID in the exception list does not mean that the send file 300 or the send initialization file 310 is not valid, since, for example, all three types of exceptions can reasonably occur due to a time delay between changes in the local database 200 and updates that /o are applied to the remote database 310. Such a delay, for example, can be caused by an overload of the communication network. In essence, validation can provide a mechanism to exclude valid exceptions from erroneous data.

For the initialization file 310 of the shipment, the OI TR 140 can compare the local database 200 and the remote database 210 by performing a bidirectional lookup of all tables in both databases 200, 210. Thus, all data in the local database 200 can be compared against of all the data in the remote database 210. Then, all the data in the remote database 210 can be compared against all the data in the local database 200. This preferably provides a comprehensive comparison of the databases 200, 210 to identify any discrepancies.

For the sending file 300, the TR 140 can compare only those data records in the local database 200 and the remote database 210, which are recorded in the sending file Z00. This primarily provides a fast-acting query 2o to detect specified discrepancies.

In another variant, a random sample of data can be made in the initialization file 310 of the shipment and/or the file 300 of the shipment. The OI TR 140 can then compare the randomly selected data in the local database 200 and the remote database 210.

The exception list 1140 may correspond to missing events, such as additions (adds), changes (tods), and deletions (deys) for the local database 200 that are inconsistent with the remote database 210. Therefore, to identify such candidate events, ОИ ТР 140 may examine the latest transactions fixed in the local database (8) of the data 200. Basically, in the registration table stored in the local database 200, an element may be formed for each fixed transaction. The element can contain the identifier of the record that was changed, the transaction (or event) that changed the record (for example, ada, tod and/or dei), a registration sequence number indicating the sequence of the transaction, etc.

A possible registration table 1100 is shown in Fig.11. In this possible variant, the sending file 300 contains transactions 1108-1114, depicted in the registration table 1100. The first element 1101 indicates that in the first transaction 1108, the (domain name server) data n! and n2 have been added to the data (domain) corresponding to identifier 41. Therefore, the identifier is a1, the event is the addition of "ada", and the registration sequence number is o 11526. Similarly, the second element 1102 indicates that in the second transaction 1109, the data n8 and pO were added to the data corresponding to the identifier a2. The third element 1103 indicates that in the third transaction 1110 the data corresponding to the identifier 43 has been deleted. The fourth element 1104 indicates that in the fourth transaction 1111, the data corresponding to the identifier 41 has been changed to add data by. For the fifth transaction 1112, the fifth element 1105 indicates that the data pb and p7 have been added to the data corresponding to the identifier az. For the "sixth transaction 1113, the sixth element 1106 indicates that the data corresponding to the identifier 44 has been changed pt") with to delete the data p3. The second element 1107 in the second transaction 1114 indicates that the data corresponding to the identifier d5 has been deleted. Accordingly, according to FIG. 1OA, the OI TR 140 may assign (1015) to each event in the update an event ID, and the event ID may correspond to a record ID. Each event in the update may be found from the event history. The event history is indexed and ordered. according to the event ID, can (ee) be generated from the registration table 1100. A possible history of events 1120 is shown in Fig. 11. Here, the first and fourth elements 1101, 1104 in the registration table 1100 indicate changes for the data corresponding to the identifier a1. Therefore , the event history 1120 contains the identifier 491 1121 and two events 1126, the addition of the axis "ada" and the subsequent change "toy" performed on the data corresponding to the identifier 41. The second element 1102 indicates the changes for the data corresponding to the identifier 42. Therefore, the history Event 1120 contains id 42 1122 and event 1127 adding "hell". History 1120 event contains id 43 1123 and event 1128 removing "de!" from subsequent change "that" indicated by the third and fifth elements 1103, 1105, which contain changes for the data corresponding to the identifier 43. The sixth element 1106 indicates the changes for the data corresponding to the identifier 44. Accordingly, the background history 1120 of events contains the identifier 44 1124 and event 1129 change "that". The OTHER element 1107 indicates the changes for the data corresponding to the identifier 5, and the history 1120 of the events contains the identifier 45 1125 and the event 1130 of the deletion of "ah!". IDs 1121-1125

IF) are ordered from a1 to 45. ime) According to Fig. 10A, the EI TR 140 can determine (1020) whether the update is valid. This definition can be performed, for example, in accordance with the embodiment of Fig. 10B. Initially, the TR 140 can compare the 60 (1022) event identifiers 1121-1125 with the exception identifiers 1140 to determine which identifiers have a match. For example, according to Fig. 11, the identifier 1121 of the event y1 in the chronology of events 1120 corresponds to the identifier of the exception a1 in "List 2" of the list 1140 of exceptions. After detecting the corresponding event and exception, the OI TR 140 can determine (1024) whether the exception is confirmed by the event. Confirmation can be done as follows. For each event identifier 1121-1125 in the event timeline 1120 , the OI TR 140 can determine whether each sequence of events 1126-1130 in the event timeline 1120 is valid. This can be done, for example, by examining the exception list 1140 to determine which exception type each exception ID belongs to, determining what a valid sequence of events should be for that exception type, and then looping through the event history 1120 of the corresponding exception ID events and event sequences for the event identifier. Valid sequences for each type of exception are detailed below. If the sequence of events 1126-1130 in the timeline of events 1120 corresponds to a valid sequence, then the corresponding event ID 1121-4125 has a valid sequence. Basically, the exception matching the exception ID can be asserted. And, the corresponding transaction 1108-1114 containing the specified event identifier is valid and not in error. In this case, the TR 140 can remove the exclusion identifier from the list of exclusions 1140. 70 For the "List 1" type of exceptions, a valid sequence of events can be (tod) (aeyi). A given sequence may contain a sequence of zero or more change events "that" followed by a deletion event "where" followed by an arbitrary event. The List 1 exception type may correspond to data that may exist in the remote database 210 but not be present in the local database 200. In this case, the data may have been recently deleted from the local database 200 and the transaction has not yet been recorded in file 300 shipments. Therefore, the dispatch file 300 could not yet be applied to the remote database 210. Therefore, this data may still reside in the remote database 210. This may be considered a reasonable distinction, since it is assumed that at some point in time the dispatch file 300 will be generated and applied to the remote database 210. Therefore, if any such sequence 1126-1130 is found for the exception ID in List 1 of the exception list 1140 in the event timeline 1120, then the corresponding transaction may be considered valid.

For example, according to Fig. 11, the identifier a5 1125 and its corresponding data have been deleted from the local database 200, as illustrated by element 1114 of the registration table 1100 and indicated by the chronology 1120 of events. During validation, 45 was deleted from local database 200, but not from remote database 210. Therefore, exclusion list 1140 contains ID 45 in List 1. According to event history 1120, event Ha 1130 corresponding to ID 45 1125, is the deletion of "where". OGTR 140 may compare a valid sequence of List 1 exceptions, ie (tod)(ae!), with event 45 1130 in event timeline 1120. i9)

Since the valid sequence of "List 1" and the event 1130 match, then the transaction 1114 deletion corresponding to the identifier 45 can be considered valid and not an error. Accordingly, the identifier a5 can be removed from the list of 1140 exceptions. aw!

A valid sequence of events for the "List 2" exception type can be (ad4a). A given sequence may contain an add event "ada" followed by an arbitrary event. The "List 2" exception type may correspond to data that exists in the local database 200 but does not exist in the remote database 210. In this case, the data may have been recently added to the local database 200 and the transaction has not yet been written to file З00 of sending. Therefore, the shipment file 300 may not yet have been applied to the remote database 210. Therefore, the data may not exist in the remote database 210. This may also be considered a reasonable variance, since it is expected that at some point in time, the shipment file 300 will be generated and applied to the remote database 210. Accordingly, if any such sequence 1126-1130 in the event timeline 1120 is found for the exception ID in List 2 of the exception list 1140, then the corresponding transaction "can be considered valid.

According to Fig. 11, identifiers 41 and a2 1121, 1123 can be mapped to data that, for example, was initially added to the local database 200. Since the sequence of events 1126, 1127 for them begins with the event of adding "ada" , then the identifiers a1 and 42 1121, 1123 correspond to valid sequences for the type and" of "List 2" exceptions. Accordingly, transactions 1108, 1109 containing the specified identifiers can be considered valid, and identifiers 41 and a2 can be removed from the list 1140 exceptions. It should be noted that the identifier a3 1123 also contains the addition event "ada" in its sequence 1128. However, the addition event (ee) "ada" is not the first in the sequence 1128. Accordingly, the sequence 1128 does not belong to the type "List 2" .

In addition, since 43 is not marked in List 2 of the list of 1140 exceptions, the ОИ ТР 140 cannot verify it according to the reliable sequence for List 2. or (then). Sequence data may contain a deletion event "dei" followed by an addition event "aada" followed by an arbitrary th event, or a change event "toy" followed by an arbitrary event. The type of exceptions "List 3" may correspond to data that exist in both databases 200, 210, but are different. In this case, the data may have recently changed in the local database 200 and the transaction has not yet been written to the send file 300 . Therefore, the shipment file 300 could not yet be applied to the remote database 210. Therefore, the data corresponding to the identifier may not yet have been modified in the remote database 210. Again, this may be considered a reasonable variance because it is expected that at some point time, the sending file 300 will be generated and applied to the IF) remote database 210. Accordingly, if any such sequence 1126-1130 is found in the event timeline 1120 for an exception ID in List C from the list of exceptions 1140, then the corresponding transaction can be considered valid . For example, according to Fig. 11, the identifiers 43 and 44 1123, 1124 can be mapped to data that has been changed in the local database 200. In the case of the identifier az 1123, the identifier 43 1123 and its data were first deleted and then added reversed with new data, so that the sequence of events 1118 may contain the deletion of "deya" followed by the addition of "ada". In the case of identifier a4 1124, the data 44 has been modified to delete the data, so that the sequence of events 1129 may contain the change "that". Since the specified sequences of 65 events 1128, 1129 correspond to the valid sequences for the type of exceptions "List 3", the transactions 1110, 1112, 1113 corresponding to them can be considered valid, and the identifiers 43 and d4 can be removed from the list 1140 of exceptions.

According to Fig. 10B, if all the exceptions marked in the list of exceptions 1140 with their identifiers have been confirmed (1024) by events, for example, if the list of exceptions 1140 is empty, then the OI TR 140 can determine (1026) the file 300 of sending or the file of initialization 310 of the shipment as valid and to inform the IOEE 100 to apply the shipment file 300 or the shipment initialization file 310 to the remote database 210.

The GOE 100 may then apply the send file 300 or the send initialization file 310 to the remote database 210 .

Conversely, if all exceptions have not been confirmed by (1024) events, for example, if the 1140 7/0 exception list is not empty, then the remaining exceptions may indicate errors in the 300 dispatch file or the 310 dispatch initialization file. Accordingly, the OI TR 140 may determine (1028) the sending file 300 or the sending initialization file 310 as invalid and log errors in the error file.

In an alternative embodiment, if, for example, the send file 300 or the send initialization file 310 was determined to be untrusted, then after a predetermined period of time, the TR 140 may 7/5 repeat the validation process against the untrusted send file 300 or send initialization file 310 for confirmation that differences are indeed fudges. This predetermined delay provides the network with more time to transmit any slow file 300, 310 sending, and more time for the databases 200, 210 to become read-unified.

In an embodiment of the present invention, the data in the remote database 210 may "lag" the data in the local database 200 by a significant time interval. Accordingly, to compare the databases 200, 210 and to detect errors, the databases 200, 210 can be made read-unified at the time when they become exact copies of each other. Basically, the remote database 210 can be brought, with the repetition of all completed transactions, to the local database 200, and the data in the remote database 210 can be made essentially identical to the data in the local database 200. c

Accordingly, to speed up the validation, any currently generated initialization file 310 of the shipment and subsequent files 300 of the shipment may be applied to the remote database i) 210 before the validation begins. In fact, the number of discrepancies can be significantly reduced. Such batch processing of the sending files 300, 310 can be defined as the formation of blocks. The first and last of these sending files 300, 310 in the block may be referred to as the lower and upper "watermarks" respectively. The first block, called the start block, may contain the initialization file 310 of the shipment. All subsequent blocks, called end blocks, can only contain 300 send files. -

Block formation can provide group validation instead of individual validation. yu

Accordingly, when an error is detected in a block, the entire block can be marked as invalid, not just the file

C00 shipment or initialization file 310 shipment where the error occurred. at

Mechanisms and methods corresponding to variants of implementation of this invention can be implemented using a universal microprocessor programmed according to variants of implementation of the invention.

Therefore, embodiments of the present invention also include a computer-readable medium that may contain instructions that can be used to program a processor to perform a method that corresponds to embodiments of the present invention. This media can include any type of disk, including floppy disk, optical disk, SO-COM compact disks, etc. with c Several embodiments of the present invention are described and illustrated in detail above. However, it should be. it is obvious that without deviating from the essence of the scope of this invention, changes and modifications of the invention can be made, which are covered by the above description and the appended claims.

Claims (28)

The formula of the invention (ee) (in 1. A method of verifying the validity of an update for a record in a remote database carried out through a network, and the update contains at least one event, which includes: comparing the record in the remote database with the corresponding record in the local to the database, - generating an exception describing the discrepancy between the remote database record and the local database record, for each discrepancy, mapping to each exception an exception identifier, with each exception identifier corresponding to a record identifier, mapping to each event in the event identifier update, where each event ID corresponds to a record ID, (F; determining whether an update is valid by comparing the events and exceptions corresponding to the record's GI. 2. The method of claim 1, wherein an update to a record is valid if each exception corresponding to the Record is confirmed by an event corresponding to the record. 3. The method according to claim 2, in which the types of exceptions include: the first type of exceptions, in which the record exists in the remote database and is not present in the local database, the second type of exceptions, in which the record exists in the local database and is not present in the remote database, and a third type of exception in which a record exists in both the local database and the remote database, but the value of a record field in the local database differs from the value of an identical field in the remote database. 4. The method according to claim 3, in which the event confirms the exception, if: the event represents the deletion of a record from the local database, and the exception belongs to the first type of exceptions, the event represents the addition of a record to the local database, and the exception belongs to the second type of exceptions , the event represents a change of a record in the local database, and the exception belongs to the third type of exceptions, or the event represents the deletion of a record from the local database followed by the addition of a record to the local 70 database, the exception belongs to the third type of exceptions. 5. The method according to claim 1, which additionally includes: repeating the method of checking the validity of the update after a given time after the update was determined to be invalid, when the update is determined to be invalid. 6. The method according to claim 1, in which the comparison includes: comparing the complete local database with the complete remote database. 7. A method of verifying the reliability of a remote database, including: transmitting to the remote database a plurality of periodic updates based on additional changes in the local database, each of the plurality of periodic updates containing at least one transaction, transmitting to the remote database an initialization update that contains the version of the local database as the local database at startup time, with the initialization update applied to the remote database, identifying discrepancies between the local database and the remote database, determining whether the discrepancies are valid, and informing the remote database to apply periodic updates, the start time of which is later than the start time of the initializing update. 8. The method according to claim 1, which additionally includes: repeating the method of checking the validity of the update after a given time after the update was determined to be invalid, when the update is determined to be invalid. about zo 9. The method according to claim 7, in which the discrepancies include: the first type of discrepancies in which the record exists in the remote database and is absent in the local database, the second type of discrepancies in which the record exists in the local database and is absent in the remote database, and the third type of discrepancy, in which a record exists both in the local database and in the remote database, but the value of the field of the record in the local database differs from the value of the identical field of the record in the remote database. co 10. A system for verifying the validity of an update for a record in a remote database carried out via a communication network, in which the update contains at least one event, the system includes: at least one processor connected to the communication network, and a memory, with connected to the processor, the memory contains a database and commands adapted for execution by the processor to implement validation of an update of a record in a remote database, which is carried out from c over a communication network, and the commands ensure that the processor executes a comparison of the record in the remote database with a corresponding entry in the local database, ;" generating an exception describing the difference between the remote database record and the local database record, for each difference, mapping to each exception an exception identifier, and each exception identifier Go! matches the record ID, matching each event in the update to the event ID, where each event ID o corresponds to the record ID, and c determining whether the update is valid by comparing the events and exceptions corresponding to the Record. pi 11. The system of claim 10, wherein an update for a record is valid if each exception corresponding to the record is confirmed by an event corresponding to the record. 12. The system according to claim 11, in which the types of exceptions include: the first type of exceptions, in which the record exists in the remote database and is not present in the local database, 5B the second type of exceptions, in which the record exists in the local database and is not present in remote database, the third type of exception, in which a record exists in both the local database and the remote database, but (F) the value of the field of the record in the local database differs from the value of the identical field of the record in the remote database. 13. The system according to claim 12, in which the event confirms the exception, if: 60 the event is the deletion of a record from the local database, and the exception belongs to the first type of exceptions, the event is the addition of a record to the local database, and the exception belongs to the second type of exceptions, the event is a change to a record in the local database, and the exception belongs to the third type of exceptions, or the event is the deletion of a record from the local database followed by the addition of a record to the local database, and the exception belongs to the third type of exceptions. 65 14. The system according to claim 10, in which, upon determination of the update as invalid, the processor repeats execution of commands to verify the validity of the update after a specified time after the update was determined to be invalid. 15. The system of claim 11, wherein the processor compares the complete local database with the complete remote database. 16. The system according to claim 10, further comprising: at least one remote processor connected to a communication network, and a remote memory connected to the remote processor, the remote memory stores a remote database and commands adapted for execution by a remote processor, to: create a new item based on new information received over the network from the database, and write a pointer to the new item in the remote database using a single continuous 70 operation, without restricting access to the remote database for searching. 17. The system of claim 16, wherein the commands are further adapted to physically delete the existing element after writing the pointer to the database. 18. The system of claim 16, wherein the single continuous operation is a save command. 19. The system according to claim 18, in which the remote processor has a word size of at least n-bytes, the remote /5 memory has a bit size of at least n-bytes, and the save command writes n-bytes to the remote memory address located on the boundary n bytes. 20. A machine-readable medium containing program instructions adapted for execution by a processor to verify the validity of an update to a record in a remote database carried out over a communication network, the update comprising at least one event, the instructions being executed by the processor: comparing the record in the remote database with the corresponding record in the local database, generating an exception describing the difference between the remote database record and the local database record, for each difference, mapping each exception to an exception identifier, where each exception identifier corresponds to a record identifier , matching each event in the update with an event ID, each event ID (8) corresponding to a record ID, and determining whether the update is valid by comparing the events and exceptions corresponding to the record. about zo 21. The machine-readable medium of claim 20, in which, upon determination of the update as invalid, the commands ensure that the validation of the update is repeated after a specified time after the update has been determined to be invalid. yu 22. The machine-readable medium of claim 20, wherein an update for a record is valid if each exception corresponding to the record is confirmed by an event corresponding to the record. at 23. The machine-readable medium of claim 20, in which the types of exceptions include: c the first type of exceptions, in which the record exists in the remote database and is not present in the local database, the second type of exceptions, in which the record exists in the local database, and absent in the remote database, and the third type of exception, in which a record exists in both the local database and the remote database, but the value of the record's field in the local database differs from the value of the identical field of the record in the remote database. in p. 24. The method of checking the reliability of data transmission through the network, which includes: identification of discrepancies . data between source and destination, identifying changes to source data that were included in the transmission, and comparing discrepancies with the changes to determine whether the transmission is valid. 25. The method according to claim 24, in which the source and destination are domain name servers. 26. The method of claim 24, wherein the differences include: a domain name that exists in the source and is absent in the destination, a domain name that exists in the destination and is absent in the source, and corresponding domain names that differ in source and destination. with 27. The method of claim 24, wherein the changes include at least one of adding the domain name to the domain name server, removing the domain name from the domain name server, and changing the domain name in the domain name server. ve 28. Apparatus for validating an update to a record in a remote database, comprising: o means for identifying data discrepancies between a source and a destination, means for identifying data changes at the source that have been included in the transmission, and means for comparing the discrepancies with the changes to determine whether transmission is reliable. (F) ko bo b5