These function will allow you to move to different records in the database. Most of the functions in this section will respect any scope limits placed on the table by the GMW_DB_Filter or GMW_DB_range functions.
GMW_DB_Move
Positions the record pointer to a particular record in a data file. This function accepts several commands. Each of these commands has an independent function equivalent that is the preferred method to use. This function remains as a legacy to its DDE counterpart:
Tthe command to execute.
<szParam> The scope or value for the command.
Returns: 4 Cursor at beginning of file (BOF)
3 Cursor at end of file (EOF)
-
Exact match not found. Cursor placed at closest match.
-
Exact match found, Cursor moved, or index successfully activated
0 Error
GMW_DB_Goto
Positions to a specific record in the table.
Syntax: GMW_DB_Goto( <lWorkArea>, <szRecNo> )
Parameters: <lWorkArea> The work area handle of the file opened by the GMW_DB_Open function.
Specifies where the cursor should be placed, and is either RecNo (dBase) or RecID (SQL)
Returns: 4 Cursor at beginning of file (BOF)
3 Cursor at end of file (EOF)
2 Exact match not found. Cursor placed at closest match.
1 Exact match found, Cursor moved, or index successfully activated
0 Error
GMW_DB_Top
Positions to the first record in the table.
Syntax: GMW_DB_Top( <lWorkArea> )
Parameters: <lWorkArea> The work area handle of the file opened by the GMW_DB_Open function.
Returns: 1 Success. Cursor placed at first record
-
Failure
GMW_DB_Skip
Moves the cursor forward or back in the table.
Syntax: GMW_DB_Skip( <lWorkArea>, <nSkip> )
Parameters: <lWorkArea> The work area handle of the file opened by the GMW_DB_Open function.
<nSkip> Specifies the number records to skip. This value can be positive to move forward in the table or negative to move backwards.
Returns: 4 Cursor at beginning of file (BOF)
3 Cursor at end of file (EOF)
1 Exact match found, Cursor moved, or index successfully activated
0 Error
GMW_DB_Bottom
Positions to the last record in the table.
Syntax: GMW_DB_Bottom( <lWorkArea>)
Parameters: <lWorkArea> The work area handle of the file opened by the GMW_DB_Open function.
Returns: 1 Cursor positioned at the last record in the file
0 Error
Quick Functions
The functions in this section are wrappers for the various other low-level functions. They are provided as a quick and easy way to perform common tasks. Be aware that although the functions are named “Quick” it is meant in the context of convenience and not speed of operation. When used in a single instance these functions are just as fast as the low-level function however, when used in loops these function perform more slowly. The reason is because these function each open/close their own work areas each time they are called.
GMW_DB_QuickSeek
This function will wrap several other DB functions to provide a quick and easy way to seek a record in the database.
Syntax: GMW_DB_QuickSeek(char *szTableName, char *szIndex, char *szSeekValue, char *szRecID)
Parameters: <szTableName> The name of the table to be opened.
<szIndex> The index to use for the table.
<szSeekValue> The seek expression to use.
<szRecID> Returned by the function. This will be the RecID of the record that is found.
Returns: 1 Success
-
Failure
-1 Invalid table
-2 Invalid Index
GMW_DB_QuickRead
This function will wrap several other DB functions to provide a quick and easy way to read a field value from record in the database.
Syntax: GMW_DB_QuickRead( <szTableName>, <szRecID>, <szField>, <szValue>, <iLen> )
Parameters: <szTableName> The name of the table to be opened.
<szRecID> The RecID of the record to read from.
<szField> The Field name to return.
<szValue> The value returned by the function.
<iLen> The length of the returned data.
Returns: 1 Success
-
Failure
-1 Invalid Table
-2 Invalid RecID
-3 RecID not found
-4 Invalid Fieldname
GMW_DB_QuickReplace
This function will wrap several other DB functions to provide a quick and easy way to replace a field value from record in the database.
Syntax: GMW_DB_QuickReplace( <szTableName>, <szRecID>, <szField>, <szValue>, <iAddTo>)
Parameters: <szTableName> The name of the table to be opened.
<szRecID> The RecID of the record to be updated.
<szField> The Field name to replace.
<szValue> The value to store in the field.
<iAddTo> Indicates if the value data is to be appended (1) or replaced (0=default).
Returns: 1 Success
-
Failure
-1 invalid table
-2 Invalid RecID
-3 RecID Not Found
-4 Invalid Fieldname
GM5S32.DLL - Updating Sync Logs
GoldMine’s GM5S32.DLL offers developers a method to update the GoldMine synchronization logs whenever an external application updates GoldMine data outside of the GM5S32.DLL or GM5 COM object functions.
GMW_UpdateSyncLog
GMW_LoadBDE must be called before calling GMW_UpdateSyncLog for the first time.
When updating multiple fields of the same record, GMW_UpdateSyncLog must be called for each modified field. However, if the first call returns 1 or 2, it is not necessary to call GMW_UpdateSyncLog for the rest of the modified fields for that specific record.
Syntax: GMW_UpdateSyncLog( <szTable>, <szRecID>, <szField>, <szAction> )
Parameters: <szTable> Specifies the table name (such as “Contact1”) or the Table ID
<szRecID> Specifies the RecID of the updated record: the correct RecID must be passed, and the RecID value must be exactly 15 characters long.
<szField> Specifies the name of the field that has changed. This parameter is only relevant when the Action parameter is U. szField is ignored when szAction is N or D.
Should be N when a new record has been appended, D when a record has been deleted, or U when a field in a record has been updated.
Returns: 32 New Tlog Entry removed
-
Deleted Tlog Entry
-
Field Tlog entry updated
4 Field Tlog entry created
2 New Tlog entry update
1 New Tlog entry created
0 Failure
GMW_ReadImpTLog
GMW_LoadBDE must be called before calling GMW_ReadImpTLog for the first time. GMW_ReadImpTLog is executed in a thread, so multiple calls can be made. Your application can determine when the imported process completes by setting the iDeleteWhenDone parameter to 1, and noting when the import file is deleted. The TLog import must have the structure shown below:
-
Field Name
|
Type
|
Length
|
Table ID
|
char
|
10
|
RecID
|
char
|
15
|
Field ID
|
char
|
10
|
Action ID
|
char
|
1
|
Syntax: GMW_ReadImpTLog( <szFile>, <bDelDone>, <szStatus> )
Parameters: <szFile> Specifies the import file name.
<bDelDone> Specifies to delete the import file when the process has completed.
<szStatus> Buffer used to monitor the status of the process. Optional, can be NULL. If passed, the szStatus buffer must be at least 10 characters long.
Returns: >0 Success. Total number of imported Tlog records.
-
Failure
GMW_NewRecID
GMW_NewRecID returns a new RecID in the szRecIDBuf. GMW_NewRecID can be called without first calling GMW_LoadBDE.
Syntax: GMW_NewRecID( <szRecIDBuf>, <szUser> )
Parameters: <szRecID> Specifies the application allocated buffer to contain the new RecID. The buffer must be at least 16 characters long.
<szUser> Specifies the GoldMine user name.
Returns: pointer to szRecIDBuf
GMW_SyncStamp
Converts Sync Stamp to time format and back.
Syntax: GMW_SyncStamp( <szStamp>, <szOutBuf> )
Parameters: <szStamp> When this string parameter is exactly 17 characters long, formatted as Date:Time in the form of CCYYMMDD:HH:MM:SS, the return string in szOutBuf is in TLog timestamp format, exactly seven characters long. When the szStamp parameter is seven characters long formatted as a TLog timestamp, the return string in szOutBuf is formatted as CCYYMMDD:HH:MM:SS.
<szOutBuf> Result of function. An empty return string indicates an error.
Returns: 1 Success
0 Failure
GM5 COM Object
Introduction
The GoldMine COM API wraps the 'C' API (GM5S32.DLL) in order to simplify access to the Name/Value pair component of the GoldMine API as well as the low-level WorkArea API. All objects are exposed using dual interfaces, in order to make them accessible to both clients that support virtual table binding, and clients that only support Dispatch Table binding (such as VBScript or JScript).
This document describes the objects in the COM API and how to use them. For specific information about available Name/Value pairs, and the transactions that can be executed, refer to “Business Logic Methods”. For specific information about the low-level WorkArea API, refer to the section "GM5S32.DLL - Low Level Access using Work Areas"
The Object Model
Figure 1 - The GM COM API Object Model
Figure 1 shows the objects in the model, together with their methods and properties. Not all of these objects are visible to the Visual Basic/Visual Basic Scripting Edition/ or Java Script client. The two enumerator objects are present to support Visual Basic’s For Each syntax.
A brief summary of the model is in order at this point. Only the top level object (GMApplication) is directly creatable by the client. This object encapsulates the functionality required to manage logins and logouts. The client would create an instance of this object, set its properties, and call Login. After a successful login, the client would then call NewContainer to create a new Name Value pair container. This would return an instance of the GMWContainer class. The container class exhibits standard COM
Collection semantics. It supports methods to allow the client to add name/value pairs, remove them, and get them by name. It also supports an enumerator that allows enumeration through all the pairs on a specific container. The use of default methods allows VB(Script) and JavaScript clients a simplified syntax for accessing the object. This will be expanded on in the specific documentation on the Container object.
When a client adds a new Name/Value pair, a GMNVPair object is returned. This can in turn behave as a collection of values, since it is possible to have single of multiple valued NV Pairs. Once again, the use of default methods simplifies the client programming model.
To Use the WorkArea API, the developer would call NewWorkArea on the Application object, which is the equivalent of the GMW_DB_Open function on the ‘C’ API. Thereafter the methods on the WorkArea class will act on the WorkArea (or table) that was opened, to allow the developer to read and update this table.
All methods on all classes make use of standard COM error handling to indicate failure. In the event of a call failing, a failure HRESULT will be returned (a VB exception), and a standard COM ErrorInfo object will be used to provide rich error information. All Error codes are made available through the EGMErrors enumeration in the type library.
The Application class.
This is the entry point to the Object Model. The Application class is call GMApplication. It can be instantiated using the ProgId “GMCOMApi.Application”.