You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This reference is compiled directly from the source code and includes comments by the software engineers who designed the automation interface.
All new content, added since the last major release is marked with a red star in the Contents tree and with a red triangle on topic page.
There are a few, but critical, syntactic differences between SAX BASIC and other BASIC languages you may have used. Be sure to read the Definitions section below, it may save you some debugging time.

External COM Programming vs ER/Studio's Macro Window

There's a different parent object in the script interpreter within ER/Studio as compared to the parent object named using an externally created executable, such as a VB program from Microsoft's Visual Studio. In the latter case, you're using ER/Studio's COM automation interface that supports BASIC. Invoke The Programmatic Id (PROGID) for ER/Studio: 'ERStudio.Application'.
Working examples of this type exist in MSVB6, .Net VB and C# and are in your ER/Studio application directory under "..\Readme\TableList.zip."
Macros which run inside ER/Studio's SAX BASIC shell will use the pre-initialized 'DiagramManager' object. There are numerous examples of this in ER/Studio's Macro Tab and in the Code Samples section of this online help file.
To summarize: Outside ER/Studio you begin with an instance of ERStudio.Application. Inside you begin with DiagramManager, and an instance is already running.

Good Programming Practice

To check for errors after method calls, use the DiagramManager.GetLastErrorCode() or DiagramManager.GetLastErrorString().

Definitions

In the list of Members of an object, the comments for METHOD, PROPERTY, PARAMETERS, and DESCRIPTION are written by the automation interface engineers. These comments include instructions or valid parameter lists. Where PARAMETERS are listed, they are usually more tightly-scoped than the universal BASIC type "Variant." Use the specific datatype as listed in PARAMETERS in your code. In the example above, you might write in your code:
Dim MyDiagram As Diagram
Dim MyFilePath As String
'**************
'NOT as Variant
'**************
MyFilePath = "C:\Model\ElleModel.dm1"
Set MyDiagram = DiagramManager.OpenFile(MyFilePath )
DEFINITION:      Function OpenFile(FullFilePath) As Diagram This is the actual source code definition. In the example, Function means a function (equivalently here, "method") is being defined.
"FullFilePath" is the only argument that OpenFile takes.
"As Diagram" means that OpenFile returns a custom datatype "Diagram." Other methods and properties may return typical data types such as Integer or String.
PARAMETERS lists any arguments the method/property takes and of what Type. In some places you may notice a difference between the datatype in the comments and the Type listed in the Parameters table. Such is the case above, where FullFilePath is listed as Type Variant in the table but as String in the comments.
The table lists the actual automation interface source-code definition, whereas the comments list the intended target type in ER/Studio.
Variant is a BASIC super-type that contains all but custom datatypes. You can generally declare any variable to be Variant and restrict it further when you use it, say, as a Boolean. The automation interface is defined in this way, but you should use the intended specific datatype in your code.
In other words, don't declare a Variant-type variable if you can use the specific data type, such as String in the example above.
Why am I using "DiagramManager" and not "Application" in the example above?
Outside ER/Studio (COM programming) you begin with an instance of ER/Studio.Application. Inside the ER/Studio Macro Editor you begin with DiagramManager, and an instance is already running. It's the only such difference in the entire object set. If you write programs only within ER/Studio, it will appear as above and you don't have to bother with it further. Otherwise, see the External COM Programming vs ER/Studios Macro Window notes above.

Syntax Notes

Note on Properties Get / Let

A property can be defined as Get/Let, meaning you can read the property (Get) or change it (Let).  However, many properties such as numeric IDs, are set by ER/Studio and are in fact read-only; they are defined with Get but not Let permissions. For example, most of the numeric IDs are Get only.
In general, if you can edit a property using ER/Studio's GUI design controls, and there exists an automation object for it, it will exist as Get/Let. If you can't edit it in ER/Studio, it's read-only (Get-only).

Note on Use of SET

The code EXAMPLES in this reference do not always use " Set ." In the SAX BASIC Editor within ER/Studio, you must use the function Set on the first instance of the object in a script (or block of code within object scope). You must use it again if the object reference changes. Example:
Set MyDiagram = DiagramManager.ActiveDiagram 'some code that closes the active diagram and opens another diagram Set MyDiagram = DiagramManager.ActiveDiagram

Note on Dim [what] As [ever]

SAX BASIC will not allow you to declare and initialize any variable in one statement. Example:
Dim MyData As Integer = 30 'No way Dim MyData As IntegerMyData = 30 'OK

Database IDs by Platform

Where a platform is specified by integer, use the following:

  • 1 Microsoft SQL Server 4.x
  • 2 Sybase System 10.x
  • 3 MS SQL SERVER 6.x
  • 4 Sybase Watcom SQL
  • 6 Informix Online
  • 7 Informix SE
  • 8 Oracle 7.x
  • 9 IBM DB2 Common Server
  • 10 InterBase
  • 11 Sybase ASE 11.0
  • 12 Sybase SQL Anywhere 5.x
  • 14 Microsoft Access
  • 15 Microsoft Access 2.0
  • 16 Microsoft Access 95
  • 17 Microsoft Visual FoxPro 2.x
  • 28 Microsoft Visual FoxPro 3.x
  • 30 Microsoft Access 97
  • 31 Microsoft Visual FoxPro 5.x
  • 32 IBM DB2 UDB 5.x
  • 33 Microsoft SQL SERVER 7.x
  • 34 Oracle 8.X
  • 35 Sybase ASA 6.0
  • 36 Sybase ASE 11.9
  • 37 Sybase ASE 11.5
  • 38 IBM DB2 UDB 6.x
  • 39 IBM DB2 UDB for OS/390 6.x
  • 40 IBM DB2 UDB for OS/390 5.x
  • 41 Microsoft SQL Server 2000
  • 42 Microsoft Access 2000
  • 43 Sybase ASE 12.0
  • 44 IBM DB2 UDB 7.x
  • 45 Hitachi HiRDB
  • 46 IBM DB2 UDB for OS/390 7.x
  • 47 Oracle 9i
  • 48 IBM DB2 AS/400 4.x
  • 49 Sybase Adaptive Server IQ 12.5
  • 51 Generic DBMS
  • 54 Sybase ASE 12.5
  • 55 Sybase ASA 7.0
  • 56 Sybase ASA 8.0
  • 57 NCR Teradata V2R4
  • 58 MySQL 3.x
  • 59 IBM DB2 UDB 8.x
  • 60 MySQL 4.x
  • 61 NCR Teradata V2R5
  • 62 IBM DB2 AS/400 5.x
  • 64 Sybase ASA 9.0
  • 65 Informix 9.x
  • 66 Oracle 10g
  • 68 Microsoft SQL Server 2005
  • 69 IBM DB2 UDB for OS/390 8.x
  • 70 Generic ODBC
  • 71 NCR Teradata V2R6
  • 72 PostgreSQL 8.0
  • 73 MySQL 5.x
  • 74 IBM DB2 UDB 9.x
  • 75 Sybase ASE 15
  • 77 Oracle 11g
  • 78 IBM DB2 for OS/390 9.x
  • 79 Sybase ASA 10.0
  • 81 InterBase 2007
  • 82 Microsoft SQL Server 2008
  • 83 InterBase 2009
  • 84 NCR Teradata 12.0
  • 85 Netezza 4.6
  • 86 Netezza 5.0
  • 87 NCR Teradata 13.x
  • 88 Netezza 6.0
  • 89 Microsoft SQL Server 2012
  • 90 IBM DB2 UDB for OS/390 10.x
  • 91 PostgreSQL 9.x
  • 92 GreenPlum 4.x
  • 93 NCR Teradata 14.0
  • 94 Netezza 7.0
  • 95 IBM DB2 LUW 10.x
  • 96 InterBase XE
  • 97 InterBase XE3
  • 98 Firebird 1.5
  • 99 Firebird 2.x
  • 100 Oracle 12c
  • 101 Microsoft SQL Server 2014
  • 102 Hive 0.12
  • 103 MongoDB 2.4
  • 104 Sybase Adaptive Server IQ 15
  • 105 Sybase Adaptive Server IQ 16
  • 106 Teradata v15
  • 107 Microsoft SQL Azure
  • 108 Microsoft SQL Server 2016
  • 109 IBM DB2 UDB for OS/390 11.x
  • 110 MongoDB 3.x
  • 111 Microsoft SQL Server 2017
  • 112 Amazon Redshift
  • 113 PostgreSQL 10.x - 12.x
  • 114 Snowflake
  • 115 Oracle 18c
  • 116 Oracle 19c
  • 117 MySQL 8.x
  • 118 Microsoft SQL Server 2019
  • 119 Microsoft Azure Synapse Analytics
  • 120 MongoDB 4.x
  • 121 JSON Instance
  • 122 Google BigQuery

 

  • No labels