TDXMXMLConf.xml – TDXMPP main configuration file.
In this section are defined macros used in all XMLConfig file. Using macros is optional.
<ConfigMacros> <Macro Name="root" Value="C:\Tsl.dev\HHApps\TDXM\Current" /> <Macro Name="dbpath" Value="$(root)\DB.RFS" /> <Macro Name="tdxmpp" Value="$(root)\TDXMPP" /> <Macro Name="configs" Value="$(tdxmpp)" /> <Macro Name="bin" Value="$(tdxmpp)\bin" /> <Macro Name="drwpath" Value="$(PredefinedMacroInputDir)" /> <Macro Name="DebugDir" Value="$(PredefinedMacroOutputDir)"/> <Macro Name="TobisAvailable" Value="1" /> <Macro Name="UIEnabled" Value="1" /> <Macro Name="TobisUser" Value="TOBISAdmin" /> <Macro Name="TobisPass" Value="TOBIS" /> <Macro Name="XMLID" Value="XMLID" /> <Macro Name="UpdateObjects" Value="1" /> <Macro Name="HandleDeletedObjs" Value="1" /> </ConfigMacros>
root - path to root folder
dbpath - path to database configuration files, i.e. hdoc.ini
tdxmpp - path to TDXMPP main folder
configs - path to folder with TDXMPP configuration files
bin - path to folder with TDXMPP binary files
drwpath - path to folder with drawing files
DebugDir - path to folder with TDXMPP output XML files
TobisAvailable - usage of this macro is mandatory - it is conneted to TDXMPP checkbox 'Use TOBIS'
UIEnabled - this macro controls UI visibility (for all nodes)
TobisUser - TOBIS user
TobisPass - TOBIS user password (crypted or not)
XMLID - unique identifier name
UpdateObjects - whether objects should be updated in HyperDoc DB or not: it should be set "0" for "Document channel" and "1" otherwise
HandleDeletedObjs - macro used in...
In this section are set attributes common for all nodes.
<NodeTemplate> <UIConfig Enabled="$(UIEnabled)" ShowClassName="1"> <States> <State name="siNotInit" icon="st_notinp.ico" /> <State name="siInputValid" icon="st_inpval.ico" /> <State name="siProcess" icon="st_process.ico" /> <State name="siReady" icon="st_ready.ico" /> <State name="siApproved" icon="st_appr.ico" /> <State name="siInvalid" icon="st_inval.ico" /> </States> </UIConfig> <Config> <DebugDir Name="$(DebugDir)" /> <TOBIS Available="$(TobisAvailable)" URL="http://localhost/tobis/TOBISWebService.asmx"> <Security PasswordMode="plain" User="$(TobisUser)" Pass="$(TobisPass)" /> </TOBIS> <HDocDB PasswordMode="ini" IniFile="$(dbpath)\hdocRFS_0.ini" UserName="" Password=""/> <ClassInfo Name="$(configs)\TDXM2ClassInfoRFS.xml" /> <ObjectsUniqueId Name="$(XMLID)" /> <Channel UpdateObjects="$(UpdateObjects)" /> <Export Apply="0"/> </Config> </NodeTemplate>
UIConfig
Enabled - variable defined in ConfigMacros section - is UIConfig enabled?
ShowClassName - showing class name?
State
name - name of node state
icon - icon for given state
Config
DebugDir Name - variable defined in ConfigMacros section - path to TDXMPP output XML files
TOBIS
Available - variable defined in ConfigMacros section - is TOBIS available?
URL - URL address to TOBIS
Security PasswordMode - this option could have next values:
plain - passwords set in open text
encrypted - passwords set encrypted
ask - TDXM asks for passwords
Security User - variable defined in ConfigMacros section - TOBIS user
Security Pass - variable defined in ConfigMacros section - TOBIS user password
HDocDB
IniFile - name of HyperDoc's ini file
UserName - HyperDoc user name
Password - HyperDoc user password
PasswordMode - this option could have next values:
plain - passwords set in open text
encrypted - passwords set encrypted
ask - TDXM asks for passwords
ini - get username and password from hdoc.ini
ClassInfo Name - name of TDXM2ClassInfo.xml file
ObjectsUniqueId Name - variable defined in ConfigMacros section - XML's unique field
Channel UpdateObjects - variable defined in ConfigMacros section - update objects in Hyperdoc database?
Export Apply - set direction of processing (0 - import to HDoc, 1 - export from HDoc)
This is an example of Node element
<Node Number="1" Assembly="TDXMInputNode" Class="Tessel.TDXM.InputNode" NodeName="InputNode"> [...] </Node>
Number - node identity number
Assembly - .NET assembly name
Class - .NET class name which serves interface for this node.
NodeName - text used in many cases (in log, in statistics) instead of Class name
This is an example of UIConfig section in Node element.
<UIConfig ID="1" Caption="Input Node" Assembly="TDXMUI" Class="Tessel.TDXM.UI4Generic" Description="Getting input XML"> <ExtraUIParams> <Param Name="ColumnNumber" Value="2" /> <Param Name="ShownXML" Value="Out" /> </ExtraUIParams> <Filters ColumnName="Object class"> <Filter name="Fastighet" expr="@Class = 'FI2FASTIGHET'" icon="i_prop.ico" /> <Filter name="Byggnad" expr="@Class = 'FI2BYGGNADSVERK'" icon="i_house.ico" /> <Filter name="Plan" expr="@Class = 'FI2PLAN'" icon="i_floor.ico" /> <Filter name="Utrymme" expr="@Class = 'FI2UTRYMME'" icon="i_room.ico" /> </Filters> </UIConfig>
ID - node identity number
Caption - node tab caption
Assembly - .NET assembly name, in all cases set TDXMUI
Class - .NET class name which serves user interface for this node, for Matching node - Tessel.TDXM.UI4Match, for Update node - Tessel.TDXM.UI4Update, for Validate node - Tessel.TDXM.UI4Validate and Tessel.TDXM.UI4Generic for others.
Description - node tab tooltip text
ExtraUIParams
Param ColumnNumber - sets the grid column number (2 to 4)
Param ShownXML - sets, which processing node XML, input (Value="Inp"), output (Value="Out") or both (Value="Both"), will be shown in the object hierarchy tree.
Filters
ColumnName – contains the legend name,
Filter name – status name displaying on the status legend,
Filter expr – expression in the XPath language, applying to the HObject section of the imported XML, defining object status,
Filter icon – status icon file name.
<Node Number="1" Assembly="TDXMInputNode" Class="Tessel.TDXM.InputNode"> <Config XSL="$(bin)\FI2002ToHDoc.xsl"> <XSDFile Apply="0" Name="$(bin)\Main_FI2002.xsd" Namespace="http://www.fi2992.se/bygginfo_001" /> <ClassInfo Name="$(configs)\TDXM2ClassInfo.xml" /> </Config> </Node>
Config XSL - XSL file, which make conversion from external format (e.g. FI2002) to Hdoc internal format (or in opposite way). Available XSL files: FI2002ToHDoc.xsl, FI2ToHdoc_ver122.xsl, HdocToFI2002.xsl
XSDFile
Apply - use validation of input XML or not
Name - file with schema for validation
Namespace - namespace for validation
ClassInfo Name - file with ClassInfo for FI2002 domain
<Node Number="2" Assembly="TDXMDomainsNode" Class="Tessel.TDXM.DomainsNode"> <Config Name="DomainsProcessingNodeConfig"> <XSDFile Apply="0" Name="XMLConnect.xsd" Namespace="http://tessel.com/HyperDoc/XMLConnect.xsd" /> <CrossDomainInfo Name="$(configs)\TDXMDBConfigRFS.xml" /> <ClassInfo Input="1" Name="$(configs)\TDXM2ClassInfo.xml" /> <ClassInfo Output="1" Name="$(configs)\TDXM2ClassInfoRFS.xml" /> <Actions> <Event Id="evKeyNonUnique" Action="skip" /> <Event Id="evNoKey" Action="skip" /> <Event Id="evErrGuid" Action="ask" /> <Event Id="evErrIdBlock" Action="ask" /> <Event Id="evGuidNonUnique" Action="skip" /> </Actions> <DataEdit Allowed="0" /> </Config> </Node>
Config Name - node config ID
XSDFile - same like in Input Node
CrossDomainInfo Name - path for DBConfig file
ClassInfo
Input - is it ClassInfo for input data?
Output - is it ClassInfo for output data?
Name - same like in Input Node
Actions
Event Id - ID for event
Event Action - action, which will be executed, when given event will be happened.
DataEdit - reserved for future extensions
<Node Number="3" Assembly="TDXMMiscNode" Class="Tessel.TDXM.MiscNode"> <Config Name="MiscProcessingNodeConfig"> <Drawings DrwPath="$(drwpath)" EmptyFileName="$(drwpath)\Empty" /> </Config> </Node>
Config Name - same like in Domains Node
Drawings - node grouping drawing import related attributes
DrwPath - path to folder where impotred drawings are supposed to be found
EmptyFileName - file name (without extension) of default drawing file to be used in case of lack of imported drawing
<Node Number="4" Assembly="TFMOValidateNode" Class="Tessel.TDXM.ValidateNode"> <Config Name="TFMOValidateNodeConfig"> <Errors> <Error Problem="IncompleteRepresentation" Action="Delete" Processor="Own"/> <Error Problem="OrphanedSpots" Action="Delete" Processor="Own"/> <Error Problem="TooShortEdges" Action="Repair" Processor="VDB"/> <Error Problem="TooSmallAngles" Action="Report" Processor="VDB"/> <Error Problem="OverlappedSpaces" Action="Report" Processor="VDB"/> <Error Problem="NonParallelEdges" Action="Report" Processor="VDB"/> <Error Problem="HolesNotInside" Action="Repair" Processor="VDB"/> <Error Problem="HolesInHoles" Action="Repair" Processor="VDB"/> <Error Problem="PolysInPolys" Action="Report" Processor="VDB"/> </Errors> <StdLayers> <StdLayer Name="BRA"></StdLayer> <StdLayer Name="BTA"></StdLayer> <StdLayer Name="NTA"></StdLayer> </StdLayers> <Problems> <Problem Name="IncompleteRepresentation" Value="0"></Problem> <Problem Name="OrphanedSpots" Value="0"></Problem> <Problem Name="TooShortEdges" Value="1"></Problem> <Problem Name="TooSmallAngles" Value="2"></Problem> <Problem Name="OverlappedSpaces" Value="4"></Problem> <Problem Name="NonParallelEdges" Value="8"></Problem> <Problem Name="HolesNotInside" Value="16"></Problem> <Problem Name="HolesInHoles" Value="32"></Problem> <Problem Name="PolysInPolys" Value="64"></Problem> </Problems> <Actions> <Action Name="Ignore" Value="0"></Action> <Action Name="Report" Value="1"></Action> <Action Name="Delete" Value="2"></Action> <Action Name="Repair" Value="3"></Action> </Actions> <Solutions> <Solution Name="Reported" Value="0"></Solution> <Solution Name="Deleted" Value="1"></Solution> <Solution Name="Repaired" Value="3"></Solution> </Solutions> <Processors> <Processor Name="Own" Value="0"></Processor> <Processor Name="VDB" Value="1"></Processor> </Processors> </Config> </Node>
Error
Problem - name of problem
Action - name of action
Processor - name of processor
StdLayer Name - name of standard layer. Now we have 3 different layers: BTA, BRA, NTA
Problem
Name - problem's name, it is used in Error element
Value - internal flag value to be used while dispatching problem programmatically and communicating with VDB library
Action
Name -action's name, it is used in Error element
Value - same like in Problem element
Solution
Name - solution's name
Value - same like in Problem element
Processor
Name - processors's name, it is used in Error element
Value - same like in Problem element
So far we cope with 9 different Problem classes. The one – incomplete representation – is a structural error and the rest consists of geometry errors.
IncompleteRepresentation – the error is connected with presumption that a spot would have its instances spread of on all standard layers (all standard layer names are defined in StdLayers subsection). If there is a spot that does not conform the presumption, the incomplete representation error type is generated.
OrphanedSpots - after deleting some objects in previous nodes (e.g. in Domains Node), some spot may exist in overlay drawing still connected to removed objects. Handling problem named OrphanedSpots allows for detecting such spots and report such situation or delete them
TooShortEdges – to assure a proper recognition of inter-spots geometrical relation the minimal length of spot’s edge is defined. Edges shorter then that are reported as edges with errors.
TooSmallAngles – to assure a proper recognition of inter-spots geometrical relation the minimal angle between two consecutive spot edges is defined. Edges with an angle smaller then that are reported as edges with errors.
OverlappedSpaces – spots can’t overlap each other. If they do so - the overlapped spaces error is generated.
NonParallelEdges – the error is connected with presumption that adequate edges of neighbourhood spots should be parallel. If they are not – the nonparallel edges error is generated.
HolesNotInside – from geometrical point of view a hole means the same as a polygon. In real life the first one is used to describe a pillar in a room and last one is used to describe a room itself. The holes not inside error is generated if a room with pillars, that cross it walls is detected. In geometry the error correspond to a polygon with holes that cross its borders.
HolesInHoles – there is no reason to consider as acceptable the situation where one pillar is defined within the other (see description of holes not inside error). In such a case the holes in holes error is generated.
PolysInPolys - there is no reason to consider as acceptable the situation where one room is defined within the other and there are no walls among them (see description of holes not inside error). In such a case the polys in polys error is generated.
Parameters such a minimal length of spot’s edge or a minimal angle between two consecutive spot edges are defined INI file that is described elsewhere.
There are 3 different action classes.
Ignore – the action consists in ignoring a drawing.
Report – the action consists in reporting to log file the detailed description of any error it concerns.
Delete – the action consists in deleting from a drawing a spot that is the reason of the error it concerns.
Repair – the action consists in repairing a drawing by changing the spot geometry. In the case there is no obvious way to do so software changes the action class from “repaired” to “reported”.
<Node Number="5" Assembly="TDXMMatchNode" Class="Tessel.TDXM.MatchingNode"> <Config XSL="HObjComp.xsl"> <XSDFile Apply="0" Name="XSD file path name" /> <HDocDB DocTimeStampField="DOCUMENT_ADD3" /> <CrossDomainInfo Name="$(configs)\TDXMDBConfigRFS.xml" /> <ExtraMatchFields Apply="0" UseIDBlock="0" ClassInfo="$(configs)\TDXM2ClassInfo.xml"> <Object Class="LEVEL_4"> <ObjectAttr Name="LEVEL_4_DESCRIPTION"/> </Object> </ExtraMatchFields> <FindDeletedObjects Apply="$(HandleDeletedObjs)" ToBeDeletedRootClass="LEVEL_7"/> <Actions> <Event Id="evErrKey" Action="fixTobis" /> <Event Id="evBadParent" Action="skip" /> <Event Id="evDuplGUIDInDB" Action="skip" /> <Event Id="evDuplKeysInDB" Action="skip" /> </Actions> </Config> </Node>
XSL - XSL file for comparing HObjects from inputing XML and from HDocDB
XSDFile - same like in Input Node
HDocDB DocTimeStampField - document containing time stamp
CrossDomainInfo - same like in Domains Node
ExtraMatchFields
Apply - if set to '1' batch processing mode uses fields defined below to match objects (if matching by GUID and DB key fails); please note that in batch mode situation when more than one object can be found using supplied "extra" matching fields is considered as an error
UseIDBlock - if set to '1' batch processing mode uses fields from FI2002 domain ID block for matching by "extra" fields; in other words it can be viewed as "simple" mode which does not require explict listing of fields to be used for matching; please note that only attributes directly moved to HyperDoc domain, can be used for matching; if this option is set to '1', explicit definitions of fields for matching will be ignored
ClassInfo - if you set 'UseIDBlock' to '1', you must also fill this attribute; it contains name of 'ClassInfo' for FI2002 domain
Object - 'Object' elements explicitly define matching attributes for given object class. Of course, you can define many attributes for many object classes
FindDeletedObjects
Apply - if set to '1' all objects, which are in DB and not in input XML, will be mark as Deleted (Status = "del")
ToBeDeletedRootClass - from this level in tree TDXM initiate marking.
Actions - same like in Domains Node
<Node Number="6" Assembly="TDXMUpdateNode" Class="Tessel.TDXM.UpdateNode"> <Config> <XSDFile Apply="0" Name="XSD file path name" /> <Actions> <Event Id="evErrRegisterNewObject" Action="ask" /> <Event Id="evErrChangeObjectIDBlock" Action="ask" /> <Event Id="evErrChangeGUID" Action="ask" /> <Event Id="evErrRegisterObjectAliasToGUID" Action="ask" /> <Event Id="evErrRegisterNewObjectWithGUID" Action="ask" /> <Event Id="evErrGetDomainId" Action="ask" /> <Event Id="evErrGetObjectClassId" Action="ask" /> </Actions> <StripDeletedObjectsInfoToAvoidDelFromDB Apply="$(HandleDeletedObjs)" /> <SelectiveVectorsUpdate> <Spots Apply="1" > <Layer Name="BRA" Status="clr" /> <Layer Name="BTA" Status="clr" /> <Layer Name="NTA" Status="clr" /> </Spots> </SelectiveVectorsUpdate> </Config> </Node>
XSDFile - same like in Input Node
Actions - same like in Domains Node
StripDeletedObjectsInfoToAvoidDelFromDB - this element controls behaviour with objects set to delete
Apply - attribute; if set to '0' all objects marked as Deleted (Status="del"), will be removed from database.
SelectiveVectorsUpdate - this element controls behaviour of spots during import
Spots - 'Spots' element (designates settings connected with 'Object overlay'; 'Redlining' overlay will be probably supported by future version of TDXM)
Apply - attribute; if set to '0' it means: "Delete existing spot data before importing new one (this is the default)"; if set to '1' it means: "Merge incoming spot data with existing one".
Layer - one or more elements containing specification of layers to be special handled;
Name - attribute contains name of a layer;
Status - attribute contains "declared" status for given layer; available values are "clr" and "del" (not implemented yet).
TDXMDBConfig.xml is a target database configuration description.
File TDXMDBConfig.xml describes relation between database structure and external domain format. It defines Object definitions and Document definition separately.
Object definition contains definition of root object and other objects which have to be exported to HyperDoc DB.
Example of Root object for RFS database:
<Object FI2Object="Root" DBObject="Root"> <Object DBObject="LEVEL_1" Opt="1"> <Attrib FI2FieldXPath="tdxm:GenerateGUID(concat('LEVEL_1',generate-id($x)))" DBField="LEVEL_1_ID" DBKey="1" /> <Attrib DBField="XMLID" Value="LEVEL_1_XMLID" /> <Attrib DBField="LEVEL_1_NAME" Value="unknown" Opt="1" /> <Attrib DBField="LEVEL_1_DESCRIPTION" Value="unknown" Opt="1" /> <Object DBObject="LEVEL_2" Opt="1"> <Attrib FI2FieldXPath="tdxm:GenerateGUID(concat('LEVEL_2',generate-id($x)))" DBField="LEVEL_2_ID" DBKey="1" /> <Attrib DBField="XMLID" Value="LEVEL_2_XMLID" /> <Attrib DBField="LEVEL_2_NAME" Value="unknown" Opt="1" /> <Attrib DBField="LEVEL_2_DESCRIPTION" Value="unknown" Opt="1" /> <Object DBObject="LEVEL_3" Opt="1"> <Attrib FI2FieldXPath="tdxm:GenerateGUID(concat('LEVEL_3',generate-id($x)))" DBField="LEVEL_3_ID" DBKey="1" /> <Attrib DBField="XMLID" Value="LEVEL_3_XMLID" /> <Attrib DBField="LEVEL_3_NAME" Value="unknown" Opt="1" /> <Attrib DBField="LEVEL_3_DESCRIPTION" Value="unknown" Opt="1" /> <Process Class="FI2FASTIGHET"/> </Object> </Object> </Object> </Object> <Object FI2Object="FI2FASTIGHET" DBObject="LEVEL_4"> <Attrib FI2FieldXPath="tdxm:GenerateGUID(concat('LEVEL_4',generate-id($x)))" DBField="LEVEL_4_ID" DBKey="1" /> <Attrib FI2Field="FI2FastighetGlobalID" DBField="LEVEL_4_GUID" /> <Attrib FI2Field="XMLID" DBField="XMLID" FI2Key="1" /> <Attrib FI2Field="FI2FastighetID" DBField="LEVEL_4_DESCRIPTION" Opt="1" MissingAction="ignore" EmptyAction="clear"/> <Process Class="FI2BYGGNADSVERK"/> </Object>
Object
FI2Object - object's name in FI2002 domain
DBObject - object's name in database
FI2ObjectXPath - reserved for future extensions
DBObjectXPath - reserved for future extensions
FI2GroupObject - defines object class from which we are extracting fields for grouping (in other words, it defines "context")
FI2GroupField - defines which field should be used for grouping
Opt - when this attribute has value equals 1, attribs value will be taken from HDoc base. In other case, this value will be taken from HDoc base or from input XML
Attrib
DBField - name of field in database
FI2Field - name of field in FI2002 domain
Value - value of specified field
FI2FieldXPath - FI2FieldXPath="ObjectAttr[@Name='FI2yyy']/@Value" equals FI2Field="FI2yyy"
DBFieldXPath - same like FI2FieldXPath
DBKey - is DBField key?
FI2Key - is FI2Field key?
Opt - is field optional?
MissingAction - what to do when field does not exist in XML. This attribute and next one can have following values:
ignore - the corresponding HyperDoc db field remains unchanged;
clear - the corresponding HyperDoc db field will be cleared;
fill:[string] - the corresponding HyperDoc db field will be set to value [string].
EmptyAction - what to do when field is empty
Process Class - next class in hierarchy for processing
Example of Documents section:
<Documents DefDocType="Fi2Dokument" IDXPath="concat('ID',/*/*/*/*/HObject/ObjectAttr[@Name='FI2FastighetSystemID']/@Value, /*/*/*/*/*/HObject/ObjectAttr[@Name='FI2ByggnadsSystemID']/@Value, /*/*/*/*/*/*/HObject/ObjectAttr[@Name='FI2UtrymmessystemSystemID']/@Value)" > <Document DocType="Fi2Dokument" > <Attrib FI2Field="FI2DokumentversionUpprattaddatum" DBField="DOCUMENT_ADD3" /> </Document> <AttribSet Name="DocAttrCommon1"> <Attrib FI2Field="FI2DokumentID" DBField="DOCUMENT_ID" /> <Attrib FI2Field="FI2DokumentKlass" DBField="DOCUMENT_TYPE_ID" /> <Attrib FI2Field="FI2DokumentversionArkiveringsdatum" DBField="DOCUMENT_ADD1"/> <Attrib FI2Field="FI2DokumentversionSlutdatum" DBField="DOCUMENT_ADD2" /> <Attrib FI2Field="FI2DokumentversionUpprattaddatum" DBField="DOCUMENT_ADD3" /> </AttribSet> <Document DocType="Mark" AttribSet="DocAttrCommon1"> <Attrib FI2Field="FI2DokumentSkala" DBField="SKALA" /> </Document> </Documents>
Documents
DefDocType - default document type
IDXPath - XPath for ID of objects
Document
DocType - type of document
AttribSet - name of used AttribSet
AttribSet Name - name of AttribSet
Attrib - same like in Objects section
TDXM2ClassInfo.xml – two files with database object classes definition. One for each domain.
ClassInfo files contains database object classes definition. In TDXM configuration you have to define two ClassInfo files, one for each domain.
Fragment of ClassInfo:
<ClassInfos TOBISDomain="TOBIS/FI2002" > <ClassInfo> <ClassName>FI2FASTIGHET</ClassName> <TOBISClassName>Property</TOBISClassName> <ClassDescription>Fastighet</ClassDescription> <DescrFieldName>FI2FastighetSystemID</DescrFieldName> <GlobalIDFieldName>FI2FastighetGlobalID</GlobalIDFieldName> <IDBlockFields> <Field>FI2FastighetID</Field> </IDBlockFields> </ClassInfo> <ClassInfo> <ClassName>FI2BYGGNADSVERK</ClassName> <TOBISClassName>Building</TOBISClassName> <ClassDescription>Byggnad</ClassDescription> <DescrFieldName>FI2ByggnadsSystemID</DescrFieldName> <GlobalIDFieldName>FI2ByggnadsGlobalID</GlobalIDFieldName> <IDBlockFields> <Field Source=".." >FI2FastighetID</Field> <Field>FI2ByggnadsID</Field> </IDBlockFields> </ClassInfo> [...] </ClassInfos>
ClassInfos TOBISDomain - domain in TOBIS
ClassInfo
ClassName - name of object class
TOBISClassName - name of class in TOBIS
ClassDescription - this is used in UI mode in treeview panel
DescrFieldName - value from this field is used with ClassDescription
GlobalIDFieldName - it is GUID for this object class
IDBlockFields
Field - name of field in IDBlock
Field Source - prefix for XPath, it shows from which object in hierarchy we have to get value of this field
This is INI file to start HyperDoc with target database.
The most important part of Hdoc.ini
file is database definition:
[Database Settings] DBType=type of database [Access Settings] MainDatabase=file path UserName=e.g. admin password=e.g. admin [ODBC Settings] MainDatabase=name of ODBC data source UserName=e.g. admin password=e.g. admin [Options] SystemDB=path to mda/mdw file [DM Settings] MainDocumentDirectory=path to HyperDoc’s main document folder
Database Settings - type of database to use. MS Access database (*.mdb) (set Access) or SQL Server database available via ODBC (set ODBC)
Access Settings - parameters of MS Access database
MainDatabase - database name
UserName - database user name
password - database user password
ODBC Settings - parameters of SQL Server database
MainDatabase - name of ODBC data source to access SQL Server database
UserName - database user name
password - database user password
Options - additional database options
SystemDB - name of mda/mdw workgroup information file (only for MS Access)
DM Settings - Document management settings
MainDocumentDirectory - path to HyperDoc’s main document folder. Used only when HyperDoc was started for the first time