MXPA97003123A - Localized sequences of multi value - Google Patents

Abstract

A computer-instrumented method for making a particular data is made available by a user program and a source program. The method includes providing a user interface for the user program to access the data to read or describe it, providing a source interface for the source program to access the data to read or write it, provide a user place and a place of origin, provide a user buffer and a source buffer to store the data, maintain the state memory to store the state of the content of the user's buffer and the contents of the source buffer, set the state of the source buffer as outdated, and the updated user buffer, when new data is stored in the user's buffer through the user interface, set the status of the user's buffer as out of date and the source buffer as updated when new data is stored in the source buffer at through the source interface, satisfy a request for the user interface to read the data when reading the contents of the user's buffer, if the state of the user's buffer is up-to-date, and convert the contents of the user's buffer origin of the place of origin to the user's place, and store the converted contents in the user's buffer, before the user's buffer is read, if the state of the user's buffer is not up-to-date, and satisfy a request of the source interface to read the particular data, when reading the contents of the user's buffer, if the state of the source buffer is up-to-date, and convert the contents of the user's buffer from the user's location to the place of origin, and store the content converted to the source buffer before the source buffer is read, if the state of the source buffer is not updated

Description

LOCALIZED SEQUENCES OF MULTIPLE VALUE Background of the Invention The present invention relates in general to the handling of data, such as text, date and coins that have different representations in different places. A computer program can use data supplied by sources that differ from the program of use or user and each other between its specific conventions to the language or the country, in terms of characters, representation, classification, date, currency, numbers, and so on. The program in use and its data sources can be in a computer, or distributed over a certain number of computers. Common examples of these distributions include extended spreadsheet programs and databases instrumented in a client-server architecture, where the client is the user or the application program, and the server or servers are the source, and sometimes also the destination of the data. To express the question in terms of client-server instrumentation, the differences in the way in which the data is represented, between the different servers and between a server and a client, can be inferred? The use and integration of the "atos" is different sources. These difficulties can occur with respect to the data themselves, as well as with respect to names, for example, database header names, which can be used to access the data. Most often, differences arise as differences between sets of characters. For example, a UNIX system in Taiwan that supports the Chinese language usually has a character set of approximately 50,000 characters. A Microsoft Windows system that supports the Chinese language, usually has a set of characters with less than half that number of characters. If a field name of a database server on the UNIX system is to be represented on the Microsoft Windows system, for example, certain characters may be lost in the conversion. These non-convertible characters may appear in a Windows application as a rectangle or as another default character. If the field name should be returned to the database server, the database server might not be able to resolve the default characters unambiguously, and therefore could no longer recognize the name of the field. A similar problem may arise in sorting by order, because the character sets may differ in the rules by which sequences are classified. For example, a set of characters can put accented characters after the corresponding non-accented character (Ñ after N), while another can put accented characters afterwards and go through all the accented alphabet (Ñ) Next is the Z). SUMMARY OF THE INVENTION In general, in one aspect, the feature of the invention is a programmed medium that can be read by computer, with instructions to have a computer keep in a user buffer to store data, information of the user's place describes a place of the user, a source buffer for storing data, origin site information describing a place of origin, and status markers indicating the status of the data stored in the user's buffer and the buffer memory of the user. origin; instructions to set the markers to indicate that the source documents are not updated, and that the user's data is updated when new data is stored in the user's buffer; instructions to set the markers to indicate that the user's data is not up-to-date, and that the source data is updated when new data is stored in the source buffer; instructions for using information from the user's place and information from the place of origin to convert the source buffer, and storing the converted data in the user's buffer, if the source data is updated, and the user's data is not are updated, and then set the status markers to indicate that both the user's data and the source data are updated; instructions for using the information of the user's place and the information of the originating place to convert data in the user's buffer, and to store the converted data in the originating buffer, if the user's data is updated, and the data of the user. source are not updated, and then set the markers to indicate that both the source data and the user data are updated; and instructions for maintaining both the source buffer and the user buffer simultaneously as instances of a particular data. The instrumentations of the present invention may include the following features. The instructions may also include instructions to cause the computer to store a second buffer in memory to store data, second location information describing a second location, and status markers to indicate the status of the data stored in the second memory. intermediate. The instructions may also include instructions for having the computer provide a first set of routines of a computer program to form an interface to the data on the user's side, to supply a second set of computer program routines to form an interface from the source side to the data, to respond to a request when reading a particular data, when reading from the user's buffer, if the request is a request from the user's memory from the interface from the user, and read from the source buffer, if the request is a request from the source side of the interface? is? e the origin, to cause the data in the source buffer to be converted and stored in the buffer of the source buffer. user if the request is a request from the user, and the user's actions are not updated, and to cause the data in the user's buffer to become n and store in the source buffer, if the request is a request from the source, and the source data is not updated. In general, in another aspect, one of the features of the invention is a computer-instrumented method for making a particular data available to a user program and a source program. The method includes the steps of providing a user interface for the user program to access the particular data to read or write it, provide a source interface for the source program to access the particular data to read or write it, provide a user place, provide a source location, provide a buffer to store the particular data, provide a source buffer to store the particular data, maintain the state memory to store the state of the memory content user buffer and the contents of the source buffer, setting the state of the source buffer so that it is no longer up to date, and the user's buffer to be updated when new data is stored in the buffer memory of the user. user through the user interface, set the state of the user's buffer so that it is already or be updated, and the source buffer to be updated when new data is stored in the source buffer through the source interface, satisfying a request from the user interface to read the particular data, when reading the content of the user's buffer, if the state of the user's buffer is updated, and converting the contents of the source buffer from the source location to the user's location, and storing the converted content in the user's buffer before the user's buffer is read, if the state of the user's buffer is not updated, and satisfy a request from the source interface to read the particular data, when reading the contents of the source buffer, if the state of the source buffer it is updated, and by converting the contents of the user's buffer from the place? the user to the place? e origin, and storing? or the content converted into the source buffer, before the source buffer be read, if the state of the source buffer is not up to date. The instrumentations of the invention may include the following features. In the method, the source program can be a server, and the user program can be a client for the server. In the method, the source program can be a database server that manages a database, and a database engine that handles requests to access the database. In the method, the database can be a relational database managed by a management system based on relational variables, including the database engine. In the method, the particular data can be the name of a field in a database record. In the method, the place of the particular data can be a defined place for a field of a database in the data source. In the method, the place of the particular data can be a defined place for a database in the data source. In the method, the place of the data in particular is a definite place for the origin? E? Atos. In the method the origin? E? Atos can be a collection of distributed objectives, and the data in particular can be in one of the distributed objects. In the method, the particular data can be in an OLE object. The instrumentations of the invention may include the following steps: providing a second interface for a second program to access the particular data to read or write it, provide a second location, provide a second buffer to store the particular data, maintain the state memory for storing the state of the content of the second buffer, setting the state of the second buffer so that it is not updated when new data is stored in the user's buffer via the user interface, or in the Intermediate memory? e origin by the interface? e origin, fix? as it does not update? this? e? the user's internal memory and as not updated the buffer of origin, and the second buffer as updated when new data is stored in the second updated memory by the second interface, and satisfying a request of the second interface to read the particular data, when reading the contents of the second updated memory, if the status of the second updated memory is updated, and convert the content of the user's updated memory from the user's place, or memory intermediate of origin from the place of origin to the second place, and store the content converted into the second buffer, before the second buffer is read, if the state in the buffer is not updated. Among the advantages of the invention are the following. The invention allows compatibility between programs and systems with different places, such as those that use alternative character sets. The invention reduces problems of loss of characters in update situations, for example. The invention allows flexible manipulation of data. For a better understanding of the nature and additional advantages of the present invention, reference should be made to the detailed description, taken in conjunction with the accompanying drawings. Brief Description of the Drawings Figure 1 is a block diagram of a system that implements the invention.

Figure 2 is a flow chart of a method of the present invention. Figure 3 is a flowchart of a method of the invention, where a particular datum is converted. Figure 4 is a flow diagram of a method of the invention, where data is edited. Figure 5 is a flowchart of a method of the invention, where the? Atos are converted. Detailed Description of the Invention Referring to Figure 1, a user program 102 running on a computer 80 communicates with a database 112 through intermediate components. In particular, the user program 112 communicates with a client process instrumented with a multi-valued sequence class provide interface services for the client side via a user side interface 142. The computer 80 communicates with the base of data 112 by the database engine 110, and the database interface 160. When a database registration is requested 112, the record is extracted from the database by the database engine 110. Typically, a layer of connectivity 108 is present, and the database engine 110 and the computer 80 communicate through the layer of the database. connectivity 108. For example, with the OnLine Workgroup Server v. 7.12 database engine, the Informix I / Connect runtime library, a database can communicate with a request program, such as the Informix Relational Object Manager v. 1.0, all of them available from Informix Software, Inc., of Menlo Park, California, E.U. Referring to Figure 2, a record with a particular data that is a sequence is read from a database (step 202). In order to have more simplicity in the present discussion, it will be assumed that the record will have a single particular character sequence data. The sequence data is initially stored in the database sequence buffer (step 204), and the CURRENT database marker is set to TRUTH (step 206). The database sequence buffer 116 is one of two buffers that are part of a multi-valued localized location buffer. The other buffer is the sequence buffer of user 114. The current marker of the database and the current user's marker are stored as MARKERS 190. Referring to FIG. 3, when the user or client requests the data ( step 201), it does so through the client-side interface or user 142, which obtains the data from the user's sequence buffer 114, and not from the database sequence buffer 116. The content of the buffer? e sequence? user 114 will be? evolved if the? or? mark the CURRENT user is TRUTH (step 209). If the article? E the base? E? Aos? Be provided to the user 102, for example, in the editing operation, the sequence is converted (step 212), as will be described below. The converter 118 converts the database sequence of its form in the database to a form appropriate for the user 102. Normally, this is a simple conversion of character sets. The conversion is based on the places of both the data item and the usage. The term "place" refers to a collection of information about specific country and language conventions for characters, classification, date, currency, numbers and so on. The place of the particular data will generally be that of its original source, the database or the database server, but it may be associated more specifically with a field of the database; for example, in a relational database, the place can be associated with a column. "The information of the place of the database is stored in the buffer of the place? e the database 124, and the information of the place of the user is stored in the memory interme? ia? the place? the user 120. The information? the place of the user can also be implicit, as for example in a converter module, such as the converter 118. The converter 118 uses the location information (steps 208 and 210) to perform the conversion in a conventional manner (step 212), such as the use of a search table of conversions The sequence resulting from the conversion is stored in the user's buffer 114, and will be designated as "user's sequence" (step 214). The sequence? E the base? E? Aos, where the conversion was performed, remains in the sequence buffer of the database 116 in its original form. In this step, both the user sequence and the database sequence represent unedited data from the database: the user's sequence was converted, but remains unpublished. The CURRENT user's marker is TRUE to match the corresponding database marker (step 216). Referring to Figure 4, when a different particular datum, in the present example a different sequence, is supplied via the user-side interface to the user's sequence buffer 114, the CURRENT database marker is set in FALSE to indicate that the database sequence no longer represents the current state of the particular data. Referring to Figure 5, when the data must be rewritten into the database through the database side interface, the base sequence? E? Atos stored in the source or buffer of the database is provided. database sequence 116 (step 426). If the marker of the ACTUAL buffer sequence is TRUE (step 248), the database sequence is supplied directly. If the database sequence marker is FALSE, the user's sequence is first converted from the user's place to the base? E data or the place of origin (step 420). The result of the conversion is stored as the sequence of the database in the database sequence buffer 116 (step 422), and the database sequence marker is set to TRUTH (step 424) . In both cases, the conversion may be delayed until the data is needed. In some cases, a completely correct version may not be possible, such as when a character in the place of origin has no corresponding character instead of the user or vice versa. For that case, a routine can be provided to invoke the conversion of user sequences to database sequences (or vice versa), to make both buffers reach their current state (their ACTUAL marker is set to TRUTH), and to set the conversion status markers in the markers 190, to indicate if errors or exception conditions occurred, and if so, where in the data. (Step 416). These routines and markers can be used at any time to determine if the conversion results, for example, in loss of characters. The problems? E data extracted from, and sent to, different places is not limited to database applications. For example, the particular project can be exchanged with more or more aional processes that have two or more places. Referring again to Figure 1, the data can be read from a second layer of connectivity? 208 through the interface 164. The same buffer of the user 114 can be used, but a second buffer of different origin 156 has the data read, and a second source place 158 has the location information. In this way, the data of an origin can be read, edited by a user, and written in a second origin with its own place. The particular data can reside in a distributed object, such as an OLE (Microsoft) or an Open Doc object (Apple Computer). An OLE object usually has a locale, simply by virtue of being an OLE object, and more information about the place can be associated with the object or data in the object.

In addition, the user or process program may also be in a distributed object with its own place. The system and methods previously written can be implemented in the framework of classes and objects defined in Microsoft Function Class (CFM), which will be written below. The particular instrumentation to be written is for the system? E base? E? Atos? The service-client. The LCString class will be effected. It includes a CString CFM, which functions as the intermediate memory of data previously described. One of the member data of an LCString is a pointer to a variable length structure of class LCSData. An LCSData structure includes the following member data. (1) m_DBData corresponds to the database sequence, and is used to store the sequence as it was received from the base engine? E? At? On the set? E DBLocale characters. pADBData represents that the characters can be in multibyte form. (2) m_ClientString is used to store the user sequence • in the character set ClientLocale. (3) mJDBLocale is used to store a unique identifier value for a specific place to access the place information for the database. The key value is of the GLocaleKey type. (4) m_fCurrent is used to store a marker that indicates that the information is updated. m_fCurrent corresponds to the user sequence marker LCStrC, or the base sequence marker? e? atos LCStrD. (5) m_DBDataLenght is used to store the length? And iaJDBData in logical characters. (6) m_AllocLenght is used to store the allocated length of m_DBData in bytes. (7) m_DBByteLength is used to store the length in bytes of m_DBData as it was stored. This value is suitable for copying sequences using functions such as memcpy. (8) m_bCumLossToDB and m_bCumLossFromDB are used to store markers that indicate whether a conversion loss occurred since the previous occasion when the markers were empty. The markers are specific to the direction of the conversion, and are carried through a job, if the job involved an LCString, or was the copy constructor. (9) tcharBuf and tcharBu Size are buffers used during operations and conversion, and can grow as needed. Functions that make use of this buffer should have a critical region identified for use in multi-threaded applications. (10) m_nRefCount is used to store a quantity counter? ? e references to the LCString. It is increased for operations, copying, and working in an LCString. Normal decrements occur in the destructor. If it is decremented to 0, the entry is deleted. If a sequence is modified by a method, a new m_nRefCount is created for the sequence modified, and the old m nRefCount of the sequence is incremented. (11) db charBuf, dbwcharBufSize, mbcharBuf, and rribcharBufSize are used buffers if the UNICODE is activated on the client. Initially, they are not assigned, but they grow as needed. The GLocale class is defined for place information. GLocaleMgr is a class for the administration of GLocals The specific premises can be selected by means of a local sequence or a GLocaleKey value. In the case of the default value, there are two places, the static place? E ClientLocale, and the place? E DBLocale database. Multiple simultaneous connections to databases, data, or other sources can be found in more than one place on the source side. The LCString class has the following constructors. (1) LCString () (2) LCString (const CString + stringSrc) (3) LCString (TCHAR ch, int nRepeat = 1) (4) LCString (LPCSTR lpsz) (5) LCString (LPCWSTR lpsz) (6) LCString (LPCTSTR lpch, int nLength) (7) LCString (cons unsigned char * psz) The previous constructors (1-7) correspond to the CString constructors named in the same way, and use the default database (DB) and the key places of the Customer's place (8) LCString (const LCString & stringSrc) makes an exact logical copy of the LCString, with the same bookmarks and updated places. (9) LCString (GLocaleKey locKey, const gl_mchar_t * psz) is for handling data from the server. (10) LCString (LPCTSTR gl, const gl_mchar_t * psz) is for handling engine data if the appropriate GLocaleKey is not available. (11) LCString (LCurrencyfi value, LPCTSTR fmt) (12) LCString (LNumber &value, LPCTSTR fmt) (13) LCString (LDateTimefi value, LPCTSTR fmt) (14) LCString (LCurrensy &valué, const LCStringfi fmt) (15) LCString (LNumber &val é, const LCString &fmt) (16) LCString (LDat? Time &value, const LCStringfi.fmt) Previous constructors (11-16) create sequences in the same places as arguments, using the formatting information in the DBLocale contained in the argument. The following attributes and methods are defined for the LCString class. int GetLengthO const returns the length of the sequence in unit? is TCHAR in the client's. int DBGetLength () const returns the length? e the DBLocale sequence in a count? e logical characters. BOOL IsEmptyO const? Evokes TRUTH, if the sequence is? E long? zero. void EmptyO causes the sequence to be an empty sequence (that is, of zero length). TCHAR GetAt (int nindex) const places the TCHAR in offset nindex TCHAR. void SetAt (int nindex, TCHAR ch) sets the TCHAR in offset nindex TCHAR in ch. LCString DBGetAt (int nindex) const results in the logical character of the nindex ofset in the DB compliant sequence that uses DBLocale character set characteristics. void DBSetAt (int nindex, const LCString & ch) sets the logical character in the nindex offset of logical character in ch.

The byte length of the sequence may change in multiple byte situations. TCHAR operator [] (int nindex) const is the same as GetAt (). operator LPCTSTR () const is an operator that gives access to the internal sequence buffer CString. operator const CString * () const is an operator that gives access to internal CString; however, this is a read-only access. The following are overloaded tasks defined for the LCString class. (1) const LCStringfi operator = (const LCStringS stringSrc) (2) const LCStringfi operator = (const CStringfi stringSrc) (3) const LCString & operator = (TCHAR ch) (4) const LCStringfi operator = (char ch) (5) const LCStringfi operator = (LPCSTR lpsz) (6) const LCStringfi operator = (LPC STR lpsz) (7) const LCString & operator = (const unsigned char * psz) The following are concatenation functions of overloaded sequences defined for the LCString class, which concatenate the second operator with the first operand. (1) const LCStringS operator + = (const CStringfi string) (2) const LCStringfi operator + = (const LCStringfi string) (3) const LCStringfi operator + = (TCHAR ch) (4) const LCStringfi operator + = (char ch) (5) const LCStringfi operator + = (LPCTSTR lpsz) The following operations concatenate two sequences, forming a new LCString instance. (1) friend LCString AFXAPI operator + (const LCStringfi yes, const CStringfi s2) (2) friend LCString AFXAPI operator + (const CStringfi yes, const LCString &s2) (3) friend LCString AFXAPI operator + (const LCStringfi yes, const LCStringfi s2) ( 4) friend LCString AFXAPI operator + (const LCStringfi yes, TCHAR ch) (5) friend LCString AFXAPI operator + (TCHAR ch, const LCString &amp) (6) friend LCString AFXAPI operator + (const LCString &si, char ch) (7) friend LCString AEXAPI operator + (char ch, const LCString &amp) (8) friend LCString AFXAPI operator + (const LCString &yes, LPCTSTR lpsz) (9) friend LCString AFXAPI operator + (LPCTSTR lpsz, const LCStringS if) The result of the above operations will be Valid on the side? the client or on the database side. The DBLocale will be set according to the following rules. In the case where the DBLocales of each of the sequences have the same set of characters, there are two possibilities. First, fall argument is valid in DBLocale, and therefore the result is valid in the DBLocale, and DBLocale is the location of the first argument. Second, if none of the arguments are valid in DBLocales (that is, they are valid only for clientLocale), then the result is valid in ClientLocale, but DBLocale is the place of the first argument. In the case where DBLocales do not have the same character set value, there are three possibilities. First, if both arguments are valid on the DBLocale side, the result is valid on the DBLocale side, and the DBLocale result will be the location of the first argument. The second argument will be first converted into the ClientLocale character set, and then converted from there to the DBLocale character set. Second, if only one argument is valid on the DBLocale side, then the result will be valid on the DBLocale side, and the resulting DBLocale will be the one that had the sequence that was valid on the DBLocale side (regardless of whether it was the first or second argument). ). This second case is a case that commonly appears to build an SQL statement. The SQL sequence will often be received from a ClientLocale source, such as a file, and will remain in the ClientLocale character set. It is very likely that the first entry will be a localized server name, name? E table, column name or text. This will often be received from the database server and will remain valid in the DBLocale. The result will be valid in the place of the name, and no loss of characters must occur. Third, if none of the arguments is valid, in the DBLocale, the result will be valid in the ClientLocale, and the DBLocale will be the place of the first argument. In the case where an argument is not LCString (usually TCHAR, CString &LPCTSTR), the result will be valid on the side of the DB place in the LCString argument, and the DBLocale will take the? LCString argument. The following are functions? E comparison? E sequences: Compare (const LPCTSTR lpsz) const compares the client side version based on the code points. DBCompare (const LCStringfi s2) const compares the DB side version based on code points. CompareNoCase (LPCTSTR lpsz) const compares the client side version based on points? E code, then? E that all characters are converted to lowercase, according to ClientLocale. DBCompareNoCase (const LCStringfi s 2) const compares the DB-side version based on code points, after all the characters were converted to lowercase, according to DBLocale. Collate (LPCTSTR lpsz) const compares the client side version based on the ClientLocale collation classification. This can be classified in a different order from the engine, even if all the characters are the same. DBCollate (const LCStringfi s2) const compares the DB side version based on a collation classification DBLocale, using GLS algorithms (Informix GLS library).

This should be used when consistency with the DB server is required. The following are simple functions of extracting subsequences. LCString Mid (int nFirst, int nCount) const extracts the nCount start from TCHAR in the nFirst offset of TCHAR in the version? The client side. If no nCount is present, take the rest of the sequence. LCString DBMid (int nFirst, int nCount) const extracts logical nCount characters that start at the logical character offset nFirst in the DB-side version. If no nCount is present, take the rest of the sequence. LCString Left (int nCount) const extracts the TCHAR from the nCount at the beginning of the client-side version. In MBCS situations, this does not coincide with partial characters at the end of the sequence. LCString DBLeft (int nCount) const extracts nCount logical characters at the beginning of the DB-side version. LCString Right (int nCount) const extracts the last nCount from the TCHAR? E the version? The la? O? The client. LCString DBRight (int nCount) const extracts the last logical character NCount? E the version? The DB side. LCString Spanlncluding (LPCTSTR lpsz) const returns a sequence containing all the characters that appear at the beginning of the client-side sequence that matches the lpsz characters. Returns an Empty sequence, if the first character is not in lpsz. LCString SpanExcluding (LPCTSTR lpsz) const returns all characters that appeared at the beginning of the client-side sequence that do not match the characters in lpsz. Returns an Empty sequence, if the first character matches an lpsz character. The following are conversion functions. void MakeUpper () converts all characters in the client-side version to uppercase. void DBMakeUpper () converts all characters of the DB-side version to uppercase, according to DBLocale. void MakeLower () converts all characters to lowercase? e the client side version. void DBMakeLower () converts all characters of the version? DB side to lowercase, according to DBLocale. void MakeReverseO reverses the order? e the logical characters in the sequence on the client side. void DBMakeReyerse () reverses the order of the logical characters in the sequence on the DB side. The following are functions for clipping white spaces. void TrimRightO trims all trailing white space characters in the client side version. void DBTrimRight () trims all trailing white characters in the DB version, according to DBLocale. void TrimLeftO trims all characters from leading blank spaces in the client side version. void DBTrimLeftO trims all leading white space characters in the DB side version, according to DBLocale. The following are search functions: Find (TCHAR ch) const and Find (LPCTSTR lpsz) const find the TCHAR index of the first occurrence of ch or lpsz within the client-side version. DBFind (TCHAR ch) sonst and DBFind (LPCTSTR lpsz) const and DBFind (sonst LCStringfi lc) const find the logical character index of the first occurrence of the argument within the DB side version. ReverseFind (TCHAR ch) sonst finds the TCHAR index of the last occurrence of ch within the client-side version. DBReverse Find (TCHAR ch) const and DBReverseFind (const LCStringfi lc) const find the logical character index of the last occurrence of the argument within the DB side version. FindOneOf (LPCTSTR lpsz) const finds the first occurrence in the version of the? O? The client? E any? E the characters in lpsz. DBFindOneOf (LPCTSTR lpsz) const and DBFindOneOf (const LCString lc) const find the first occurrence of the DB-side version of any of the logical characters in the argument. The following provide access to the sequence instrumentation buffer as vectors and C characters: LPSTR GetBuffer (int nMinBufLenght) obtains a signal to the internal buffer TCHAR of the client-side version. It also guarantees that the buffer is large enough to hold nMinBufLenght of the TCHARs. void ReleaseBuffer (int nNewLenght = 1) is used to adjust the internal variables after a call GetBuffer and direct manipulation of the internal buffer TCHAR. If nNewLength is > = 0, a TCHAR null terminator will be inserted in the nNewLength offset of TCHAR. LPTSTR GetBufferSetLenght (int nNewLength) returns a pointer to the client-side buffer, after it conforms to nNewLength in the TCHARs. void FreeExtraO releases any surplus memory associated with the client-side stream buffer. LPSTR DBGetBuffer (int nMinBufLenght) gets a flag to the internal byte buffer for the DB side version. Also that the buffer is of sufficient size to have logical characters nMinBufLength. void DBReleaseBuffer (int nNewLength = -1) is used to adjust the internal variables after a DBGetBuffer call and direct manipulation of the internal DB buffer. If nNewLength is greater than or equal to zero, a logical null terminator character will be inserted into the logical character nNewLength. LPSTR DBGetBufferSetLength (int nNewLength) returns a pointer to the buffer on the DB side, after it is set to nNewLength in logical characters. void DBFreeExtra () frees any excess memory associated with the sequence buffer? the DB side. The following methods will also be defined: -LCString () is the destructor. int GetAllocLenghth () const gets the length of the client-side buffer in the TCHARs. DBGetAllocLenghtO gets the length of the buffer on the DB side in bytes. This size is expressed in bytes, because the character set in the DB server may not be of the same type (? E single byte,? E multiple byte, broad characters) as the machine? The client. BOOL CumLossToDBO const and BOOL CumLossFromDBO const result in TRUTH, if there was a loss of characters (one character in a character set that has no corresponding character in the other, so that a substitute character is put in its place) during a conversion? This is the last time the internal mark was re-set (or? it is the initial creation). These marks are preserved even though there is assignment to LCString (although not concatenation) and through the copy constructor. The loss of characters does not refer to a change in the number of logical characters, but rather in a loss? E means?, because the original sequence can not be reconstructed again. void ResetCupiLossToDBO and void ResetCumLossFromDBO reset the internal state of the marker (in FALSE). SetDBLocale (GLocaleKey key) sets the DBLocale side to the key. If the character set from the previous place is not the same as the key character, and if the sequence was only on the server side, the. The first sequence will be converted to the customer's place before the new place replaces the previous one. The resulting value is the argument (key). SetDBLocale (LPCTSTR loe) sets the DBLocale side to a place defined by loe. If the character set of the previous place is not the same as that of loe, and if the sequence was only updated in the server's lane, the sequence will first be converted to the place of the client, before the new location replace the previous one. The resulting value, if successful, is the GLocaleKey value created for loe. ForceToDBO causes the sequence to be updated on the DB side. This function will not eliminate exceptions, but rather will trap the exceptions, and will produce an error code if any exception or any other problem is encountered. There will be valid data (perhaps only the empty sequence) even if it results in failure. This function can be used to avoid some exceptions, especially if there were otherwise simple application methods, such as GetLenghtO. The resulting codes are as follows: (1) LC_FORCESUCCESS: a successful result. The sequence was successfully converted, or was already updated on the DB side, and no data loss markers were updated for the conversion (in any of the addresses). (2) LC_FORCEMEMORY: a memory error was found during the conversion process. The resulting sequence on the DB side will be a sequence of zero length, and the data loss markers will be set by the conversion to DB. (3) LC_FORCEGLSCONVERSIONMISSING: there was no conversion for the two character sets involved, and they are not the same set of characters. This means that part of the GLS is not installed, environment variables can not be set correctly, or simply are not available in any support for this set of languages. The resulting sequence on the DB side will be a sequence of zero length, and the data loss markers for DB conversion will be set. (4) LC_FORCEGLSCONVERSIONERROR: an error (which is not data loss) occurred during the conversion process. The primary source of this type of error would be: an illegal character was found. The resulting sequence on the DB side will be a long sequence? zero, and the? rans? e? e? at? e? t? e? t? will be set for conversion to DB. (5) LCJFORCEDATALOSSNOW: the sequence was converted by this function, but some ?os were lost during the conversion. This result will only appear if a conversion was made and data loss occurred. (6) LC_FORCEDATALOSSPREVIOUS: the sequence was successfully converted, without loss of data in this conversion, but the accumulated data loss marker remains fixed. This could mean that some previous operations had losses in previous operations. This could apply or not to the sequence in question. (7) LC_FORCEDATAPREVIOUSLOSS: no conversion was required, because the sequence was already updated on the DB side. However, at least one of the four data loss markers was fixed. The loss can be correlated with the content of the sequence in question. ForceToClientO causes the sequence to be updated on the client side. This function will not make exceptions, but rather will trap exceptions, and will produce a code and error if it finds an exception or any other problem. There will be valid data (maybe only an empty sequence) even if it results in failure. This function can be used to avoid some cases of exception, especially if there were otherwise simple application methods, such as GetLengthO. The resulting codes are the following: (1) LC_FORCESUCCESS: a resulting value with success. The sequence was effectively converted, or was already updated on the client side, with no data loss markers for the conversion (in any direction). (2) LC_FORCEMEMORY: a memory error was found during the conversion process. The resulting sequence on the client side will be a zero-length sequence, and the data loss markers will be set for conversion to the client. (3) LC_FORCEGLSCONVERSIONMISSING: there was no conversion for the two sets of characters involved, and they are not the same sets of characters. This means that part - the GLS is not installed, that the environment variables were not set correctly, or simply that there is no support for this set of languages. The resulting sequence in the client's lane will be a zero-length sequence, and the data loss markers will be set for conversion to the client. (4) LC_FORCEGLSCONVERSIONERROR: an error (which is not data loss) occurred during the conversion process. The primary source of this type of error could be that an illegal character was found. The resulting sequence on the client side will be a sequence of zero length, and data loss markers will be set for conversions to the client. (5) LC_FORCEDATALOSSNOW: the sequence was converted by this function, but some data was lost during the conversion. This result will only appear if the conversion was made and produced data loss. (6) • LC_FORCEDATALOSSPREVIOUS: success was achieved to convert the sequence, without loss of data for this conversion, but the cumulative data loss marker is still set. This could mean that in some previous operation there was data loss in two previous operations. This may or may not apply to the updated sequence. (7) LC_FORCEDATAPREVIOUSLOSS: no conversion was required, because the sequence was already updated on the DB side. However, at least one of the 4 data loss markers was fixed. The loss may or may not relate to the content of the sequence in question. Unlike the previous methods, UpdateC (BOOL NoExceptions = FALSE) and UpdateDB (BOOL NoExceptions = FALSE) are internal (protected) methods that support the ForceToClient and ForceToDB routines, but a new argument was added. If the argument is TRUE, all exceptions (including memory exceptions and produced by new ones) will be trapped and converted to resulting values. In addition, errors detected within this routine will produce error values if the argument is TRUE; they will make exceptions if the argument is FALSE. The resulting values in question will match the resulting values of ForcetoClient and ForceToDB. The following method provides an equivalent to a motor function: DBSafeMind (int int, int length) const uses base length values in bytes (as opposed to the base? E logical characters for most? E? Ms methods? os). If it results in values? E longitu? In the partial logical characters at the beginning or at the end of the sequence, the partial character bytes are replaced by the space character (""). If the sequence is "A1A2B1B2C1C2" (ie, 3 multi-byte characters), then DBSafeMin? D, 4) will result in "B1B2",? On? E the superin? Ice represents the subin? Ices? E bytes for characters of multiple bytes. The following routines allow for the ability? of reference account: LockBuffer () matches the CString password, and produces a flag to the client's valid buffer. This signal turns off the reference count for this case of LCString. This means that a separate copy of the internal data will be made for this case (if there are other cases oriented to this data), and if another LCString case is assigned / copied while it is closed, a separate copy of the data will be created. data for the destination instance (as opposed to the reference count when it is not closed). LockBufferO assumes that the user will modify the buffer and, therefore, invalidates the contents of the buffer DB. Likewise, if any access is made to this instance that requires the update of the DB side, it will produce a failure in a DECLARATION. LockDBBuf er () is equivalent to LockBuffer, but it produces a signal to the valid intermediate memory on the DB side. This call turns off the reference count for this case of the LCString. This means that a separate copy of the internal data will be made for this case (if there is any other case oriented towards this data), and if another LCString case is assigned / copied while it is closed, a separate copy of the data will be created to the destination case (as opposed to the reference count when it is closed). LockDBBuffer () assumes that the user will modify the buffer and, therefore, invalidates the contents of the client's buffer. Likewise, if any access is made to this case that requires the client side, the update will fail in a DECLARATION. ReleaseBuffer () opens the buffers closed by LockBuffer () or LockDBBuffer (). PrevCharIndex (int index) const,? The TCHAR deviated (index) in the sequence, will determine the TCHAR index of the previous logical character in the sequence on the client side. The resulting effective value will be greater than or equal to zero, and less than GetLengthO. If the index is 0 (pointing towards the beginning of the sequence), or if it is outside the sequence, the resulting value will be -1. This should be used in place of the "-" operator to modify the index. GetCharValue (int index) const, of a diverted TCHAR (index) in the sequence on the client side, produces the logical character value in that place. The resulting effective value will be O < = resulting value < = UCHAR_MAX (255 or 65535 for most Microsoft cases). The resulting value will be 0 if it points to the end of the sequence marker (== GetLenghtO). If the index is outside the sequence, the resulting value will be -1. Each of the following functions tests the logical character in the TCHAR offset (nindex). Each function results in TRUE (1), if the logical character has the characteristic. If it results in FALSE (0), if the character does not have the characteristic, or if it is outside the range of index values for the sequence. (1) IsAlnum (in1 nindex) const (2) IsAlpha (int nindex) const (3) IsBlank (int nindex) const (4) IsControl (int nindex) const (5) IsDigit (int nindex) sonst (6) IsGraph ( int nindex) sonst The following methods give support for handling? e exceptions: GLosaleMgr:: Init (void (*) (int, LPCTSTR, LPCTSTR) DoExsept) installs the "exceptions" handle defined for the applications, and then initializes GLocaleMgr data. This function should be called immediately after a LoadLibrary for the DLL. The argument is the substitution of applications for the default function described below. It allows the handling to the measurement of the errors. void DoExsept (int error, LPCTSTR msg, LPCTSTR arg) is the default handler "? e exception? the user" for the LCString DLL. It makes a message appear, and then it starts a CUserException. Any substitution can process the argument in any way (storing it elsewhere), and producing any kind of exception (it can have multiple specialized exceptions containing error number and message, if desired). To use LCString, the GLocaleMgr should be fixed with default places before a connection is made to the server. Further, an additional operational location must be entered with GLocaleMgr:: GLAd? Reference before the connection, and the GLocaleKey must be stored for use in the creation of LCStrings. If it is a database that has one location per column (field), immediately after the additional location information of the connection must be obtained and placed in the GLocaleMgr, and the resulting GLocaleKeys stored. If the DBLocale is not known before the connection, the following procedure can be used. The DBLocale by default must be set equal to the client's location (or any arbitrary desired location that can be related to another base? E? Atos). The database is opened and consulted to determine the location information, and the DBLocale can be fixed to? Ecuately. All the initial transfer information to do this is limited to the 7-bit ASCII section that is common to all character sets in and in the same basic place. One way to create an LCString is "new LCString (locKey, buffer)",? On? E the "locKey" is a GLocaleKey and "buffer" is a variable "char *". The internal memory must have a zero terminator in it. If it is a fixed character field, it must have enough space to have the terminator, or it must be moved to an intermediate memory large enough to contain the zero terminator. This buffer will be based on characters, as well as all transfers from the database server must be in multi-byte format. To write data to the database, DBGetBuffer () and DBGetBytes () are used to access the characters to be copied back to the server. These methods will always have the sequence in the format char *? E multiple bytes that are expected to be necessary for transfer to the server. If a pad is used, it is done (for example, to fixchar) before the buffer methods are called.

To write a field in a database record, an instrumentation that uses LCString can work in the following way. m_DBData is received from the database engine 110 and stored in the buffer? e sequence? e the base? e data 116. If a conversion is required for the character set for the user, the converter 118 would perform the conversion using m_DBData, and the location information? e GLocale (step 212). GLocale is available to me through GLocaleKey m_DBData. m_DBData has a pointing to m_DBLocale. GLocaleKey represents the key value to access the GLocale information in the GLocaleMgr. GLocaleMgr has a static member that represents the user's place. The member of the tcharBuf data can be used during the conversion as a buffer. The results of the conversion are put into the buffer? E the sequence? The user 114 as m_ClientString. m_DBData remains unchanged. The user can then alter, modify, or in some other way edit m_ClientString stored in the buffer of user sequence 114. If this edition is performed, the resulting sequence can be repositioned in the LCString by means of the assignment operation. The LCStrC user's bookmark still has the value TRUE, while the bookmark? E the LCstrD database is set to FALSE. The record can then be returned to the database. This is designated as an UPDATE operation. This operation usually involves the construction, through an appropriate tool, of an UPDATE sequence. The sequence is sent to the database engine to modify the database. When building the UPDATE sequence, access the m_ClientString user sequence, because it represents the most up-to-date information if an edit was made in the registry. A conversion is performed to convert the m_DBData database sequence to be a converted form of the newly edited user sequence. The fact that m_ClientString was edited can be terminated by examining the status of LCStrD. Tests can be performed on m_DBData to ensure that a valid conversion resulted. Appropriate appropriate markers can be set so, for example, a loss of characters occurred. The user can test these markers to determine if the conversion is valid. These tests may occur before the sequence, the base, and the data were written back into the database.

The results of the conversion are stored in DBData, and the mark? Or? E sequence of the LCStrD database is reset to TRUE. If no editing was done in m_ClientString, no conversion would be necessary. The UPDATE command can be rebuilt using m_DBData, the database sequence. The present embodiment is not limited to editing operations, as described above. For example, if the sequences of two different places are compared in alphabetical order, the order in the comparison may vary from country to country. Therefore, the comparison could make it unimportant, or an invalid operation. An initial test, "entered the place" the user, could? Etermine this before? A call is made to the server. The invention was described in terms of a modalida ?. However, this invention is not limited to the embodiment shown and described. Rather, the scope of the invention is defined by the appended claims.

Claims (13)

1. A computer program that resides in a medium that can be read by computer, that includes the instructions to make the computer: keep in a memory a buffer for the user to store data; keep in a user memory information of the place that? the place? the user; keep in memory an intermediate memory? e origin to store? atos; keep in a source memory information of the place that describes the place of origin; keep in a memory markers to indicate the state of the data stored in the buffer of the user and the buffer? the origin; set the? ores? this to indicate that the source data is not updated, and that the user's data is updated when new? atos stored in the user's buffer; set the status markers to indicate that the user's data is not up-to-date, and that the source data is updated when new data are stored in the memory interme? ia? e origin; use information from the user's place and source information, to convert data to the source buffer, and save the converted data to the user's buffer, if the source data is updated and the user's data is not updated , and then set the status markers to indicate that both the user data and the source data are updated; use the information of the user's place and the information of the place of origin to convert data in the user's buffer and store the converted data in the home memory of origin, if the user's data is updated, and the data of source are not updated, and then set the status markers to indicate that both the source data and the user data are updated; and maintaining both the buffer of the source and the user's buffer simultaneously as instances of a particular data.

The program of claim 1, further comprising instructions for: providing a first set of computer program routines to form a user-side interface to the data; provide a second set of computer program routines to form an interface of source side to the data; respond to a request to read a particular document, when reading from the user's buffer, if the request is a request from the user side of the interface? the user's side, and read from the source buffer , if the request is a request from the origin side of the interface? the origin? to make the? atos in the home memory of origin are converted and stored in the buffer? the user, if the request is a request? the user side, and? atos? the user are not updated; and making the data in the user's internal memory converted and stored in the user's buffer if the request is a request from the source code, and the source data is not updated.

3. A computer-instrumented method for making a particular data available for a user program and source program, comprising: providing a user interface for the user program to access the particular data for read or write; provide an origin interface of the source program to access the particular data to read or write; provide a user place; provide a place of origin; provide a user buffer to store the particular data; provide a source buffer to store the particular data; maintain a state memory to store the state of the contents of the user's buffer, and the contents of the source buffer; setting the state of the source buffer as outdated, and the user buffer as updated when new data is stored in the user's buffer through the user interface; setting the state of the user's buffer as out of date, and the source buffer as updated when new data is stored in the source buffer through the source interface; satisfy a request for the user interface to read the particular data, when reading the contents of the user's buffer, if the state of the user's buffer is updated, and convert the contents of the buffer of the place's origin of origin to the user's place, and saving the converted contents in the user's buffer before the buffer is read? the user, if the state of the user's buffer is not updated; and satisfying a request from the source interface to read the particular data when reading the contents of the source buffer, if the state of the source buffer is updated, and converting the contents of the user's buffer from the location of the user to the place of origin, and storing the converted contents in the source buffer, before the source buffer is read, if the state of the buffer? e source is not updated.

4. The method? E claim 3, wherein the source program is a server, and the user program is a client to the server.

The method of claim 4, wherein the source program is a database server that manages a base of? Aos, and a database engine that handles requests for access to the database.

6. The method of claim 5, wherein the database is a base of relational? Ates to? Ministra? A by a system??? Or? Relational database, including the database engine. .

7. The method of claim 5, in which the data in particular is the name of a field in a base record? E? Atos.

8. The method? E reivin? Ication 5, where the place of the data in particular is a local defini? O for a field of a database in the data source.

The method of claim 5, wherein the place of the particular data is a defined place for a database at the origin? E? Atos.

10. The method of claim 5, wherein the place of the atoate in particular is a place? Efini? O for the origin? E? Atos.

The method of claim 3, wherein the data source is a collection? E istributed? Objects, and the particular data is in one of the distributed objects.

The method of claim 11, wherein one of the distributed objects is an OLE object.

13. The method? E claim 3, which also includes: providing a second interface for a second program to access the particular data to read or write; provide a second place; provide a second buffer to store the particular data; maintain a state memory to store the state of the contents of the second buffer; Set this to the second memory as it does not update how new "memory" is stored in the internal memory, the user through the interface, the user, or the user. intermediate memory? e origin through the interface? e origin; setting the state of the user's buffer as outdated, and the home memory as out of date, and the second buffer as updated when new data is stored in the second buffer through the second interface; and satisfy a request from the second interface to read the data by reading the contents of the second buffer, if the status of the intermediate memory is being updated, and converting the contents of the buffer of the user from the user's place, or the source buffer? is? e the place? e origin, to the second place, and store the converted contents in the second interim memory, before the second buffer is read, if the state of the second buffer is not updated. SUMMARY A computer-instrumented method to make a particular data available through a user program and source program. The method includes providing a user interface for the user program to access the data to read or describe it, providing a source interface for the source program to access the data to read or write it, provide a place for the user and a place? e origin, provide an intermediate memory? e user and a source buffer to store the? ato, maintain the state memory to store the state of the contents of the user's buffer and the contents of the memory source buffer, set the status of the source buffer as out of date, and the user buffer as updated, when new data is stored in the buffer memory? the user through the user interface, set the state of the user's buffer as not updated and the source buffer as updated when new data is stored in the buffer of origin Through the source interface, satisfy a request for the user interface to read the data when reading the contents of the user's buffer, if the state of the user's buffer is updated, and convert the contents of the memory intermediate? e origin? the place? e origin to the place? the user, and storing the contents converted into the internal memory? the user, before the user's buffer is read, if the state? e the memory intermediate of the user is not updated. , and satisfy a request from the source interface to read the particular data, when reading the contents of the buffer, the user, if the latter is in the middle memory, and the source is updated, and convert the contents of the user's buffer from the user's place to the place of origin, and store the contents in the intermediate memory before the middle memory is read? origin, if the status of the intermediate memory of origin is not updated.