by John Ragan
|
Select A Section home public service database mgr. data access data modeler site notes |
Currently In This Section CoreReader Data Gateway Server Documentation ( Please Scroll Down ) |
Pages In Section summary data sources user manual advanced ops data gateway downloads |
|
This is a legally copyrighted work, ( Has not been substantially updated in years. A report of erroneous or misleading information will be appreciated. ) Beginners; Please stop here and go to the basic documentation. This document is not needed for point-and-click queries.
__________________________________________________ . . Chapter
__________________________________________________ Copyright __________________________________________________ CoreReader Technology
_________________________ The CoreReader documentation is in three books. Book 1:
The point-and-click character of CoreReader allows a beginner to benefit from the system without mastering any documentation. The section on connecting to data sources is probably necessary, but the other sections can wait until the beginner wants them. Book 2:
Book 3:
__________________________________________________ Chapter Introduction __________________________________________________
_________________________
After installation, CoreReader looks like any other system with its GUI interface. However, behind that pretty face is a powerful data server which can interface with other systems. As you read on, you will find that CoreReader uses true enterprise management to create what has become known as grid computing. The data server is a powerful interface between systems, such as web servers on one side and an organization's data sources on the other. Although easy to operate, CoreReader can turn a multitude of data sources of all types and brand names into a single data source for other systems. Through CoreReader, other systems can draw on DB2, AxleBase, Oracle, Ms. Sql, MySql, FireBird, Access, spreadsheets, etc. etc. All from one simple and configurable source. Additionally, it turns some monumental development problems into trivial operations because CoreReader also has its interactive point-and-click graphical environment. Connections, queries, and configurations can be developed and tested interactively, and then put into production simply by running the server. After installation, use the GUI to build a library of connections. Interactively create and save queries. Then run them from other systems. The CorePort interface is built into the server. It presents a simple interface to which the developer can program. It consists of a few commands and the returned data set. Caution: The operation of this system can transcend the boundaries of many systems, networks, organizations, and even nations. The developer needs to be aware, not only of the systems into which he ties, but also what those systems are tied into. Without that understanding and knowledge, bizarre things can result. A sophisticated CoreReader installation can include database servers, data sockets, operating systems, network servers, file servers, routers, etc. etc. If a system someplace in all of the linked systems happens to fail or crash, CoreReader will attempt to continue operations, and the CorePort will try to convey error messages from all sources. If a failure starts to bring everything down, CoreReader will continue logging activities until it becomes impossible, so verbose logging is highly recommended whenever possible.
_________________________ When the basic CoreReader GUI is installed on the system, it also installs the server with its interface. Remove the GUI if it is not wanted. The server will remain functional. The CorePort interface provides an interface to the server for external client apps. The dll is what installs on the computer system, and the CorePort is an object inside it. System component inventory:
_________________________ A compiled demonstration application is available for download from the web site under the same license terms. Download and install as you do the other items. The CoreReader server must be installed,
Then install the demonstrator and run it. It requires no configuration. It simply has buttons which demonstrate various parts of the server interface by returning data sets and performing other operations. The main purpose of the demo app is to demonstrate how to develop an app that uses the server. It uses the commands and returns as described in the API in the last section of this document. It is designed to even use mistakes to demonstrate, and (hopefully) will give a quick idea of program flow. The demo app can also be used to test the system. It is so simple that, when in doubt, one can quickly load it and test the server.
__________________________________________________ Chapter Development Notes __________________________________________________
_________________________
Development Notes CoreReader respects mathematical logic, so it numbers the first element of a set as the first element. The number of elements in a set is the number of elements in the set. The number of elements in a set is not the number of elements in the set minus one. If you want the fourth row, tell the CorePort that you want row number 4; not row number 3. If you want the first row, tell it that you want row number 1; not the zeroth row. ( Please look at the absolute stupidity of that last paragraph to see why I am adamant about this matter. I am just plain tired of dealing with a lack of logic, regardless of how many million people do it and regardless of why it started. ) ( Furthermore, new programmers should not be subjected to such a nonsensical lack of logic in what is supposed to be the epitome of logical professions! )
Development Notes Developers must be familiar with the basic operations documentation, and may also need some parts of the advanced documention. There are three pieces that will be used; the GUI, the server, and the client app. The GUI works directly with the server. All other systems are client apps. During each startup, CoreReader must provide numerous services such as checking the server toggle and loading connections. These operations take some time, so the startup should be done before operation commands. On a heavily loaded site, the startup might possibly be done once. When and how to start CoreReader should be taken into account when designing the site. Connections to data sources can also require a great deal of time. If the data source is a database server, latency sometimes becomes even greater. Allow enough time in the operations for a connection to be made. ( The server interface is similar to that of the AxleBase interface. ) There is an interface object named CorePort within the server. Operations are begun by first instantiating the CorePort. Once values are set in a session, they remain extant until changed or until the session ends. The commands are capable of returning error messages, so client systems should be prepared to act upon errors. If there is no return, success should be assumed. The developer must be aware of the data source. Not all data sources can perform all of the CorePort and CoreReader operations. Some, for example, cannot return a valid data type. A query result will remain available until the next query. It is the responsibility of the client to insure that the result being retrieved is the expected one. When a query is run, the buffers are initialized. For security issues, see the Security section.
Development Notes CorePort is the interface in the server. After it is loaded, the CorePort is immediately ready to receive commands. The CorePort object instantiation does not initialize or start server. The client system must issue the load command to CorePort to start the CoreReader server. Depending on the language being used and how the program is constructed, the startup might be something like
Development Notes The GUI must be used to:
If free-form SQL statements will be permitted, it is recommended that some typical statements be tested against the data sources from the GUI. Although not obvious in ordinary operations, the server is also the back end for the GUI. It thereby provides a powerful development tool by allowing commands, queries, and configurations to be tested interactively. Debugging an installation, at least the part controlled by CoreReader, is made trivial. The GUI should NOT be used during production server operation. Also, because the GUI and the CorePort use the same server and the same database, the two can conflict when used together for debugging.
Development Notes Logging can be turned on in the GUI configuration screen. Additionally, verbose activity logging can be turned on. If the environment can support the load, logging with verbose logging is highly recommended for error detection and for security. Some thought should be given to log truncation. CoreReader automatically truncates the log when he is started. The truncation is determined by the value set in the configuration screen. If the server has been running for some time and has a million log records, but the max records value is only ten thousand, the file may receive an unexpectedly large truncation. The opposite situation can also be a problem. CoreReader truncates only on startup. Therefore, if a heavily used installation is left running day and night for an indefinite period, the log may need to be managed manually. Note that the system will not be adversely effected by a file deletion. If his log file is deleted, CoreReader simply re-creates it and continues logging. CoreReader is perfectly happy with having his log file copied offsite and manually deleted.
Development Notes The number of possible open connections is unlimited. This unfetters the client operations in a very large server environment, but the downside is that the client can overwhelm the computer with a vast number of connections. The freedom means also that the client is responsible for connection management. The CoreReader server does its own connection pooling instead of using Microsoft's. This gives greater control to the server and to the clients. - A stored connection may have multiple open instances.
For purposes of illustration, let us say that there is a connection named site_conn_46 on file in the CoreReader database. Client A wakes up and tells the server to open connection site_conn_46. The server connects and returns index number 1. Thereafter, client A will use connection number 1. Now, we allow client B to tell the server to make the same connection, site_conn_46. The server opens another instance of site_conn_46 and returns index number 2 to client B. Thereafter, client B will use connection number 2. Clients A and B are connected to the same source, but they will receive data through different pipes. Now, suppose that client A needs to query another data source while continuing to work with the first one. He tells the server to open the connection named site_conn_211. The server returns index number 3 for that connection. Now client A is running queries against connections 1 and 3. Making a connection takes a lot of time, and each connection uses system resources. Client A has a trusted co-worker process, client C, which comes on line. To conserve resources, client C asks A what connection to use. A tells C to use connection number 1. Thereafter, client C runs queries against the same connection, number 1, that A is using. Client C needs an additional connection, so it tells the server to open site_conn_801. The server returns index number 4.
Development Notes After loading, an orderly termination is the responsibility of the client system. The CoreUnload command tells the server to perform an orderly shutdown. The server then goes through its usual shutdown process. The client then sets the server object to nothing. If the object is destroyed without an unload command, logging, error trapping, and other necessary operations will not be performed. Also, if the object is destroyed without the unload command and the server is performing an operation, the local object destruction may succeed while failing to destroy the server instantiation. If the unload command is issued without destroying the object, there is a possibility that the server will not be totally unloaded, resulting in an unstable system. ** Therefore, the recommended way to cease operations is to first issue the unload command and then destroy all of the client app's objects. ** A shutdown after every query is not necessarily a good thing. As noted elsewhere, the system startup can take a lot of time, and making data connections can take even more time. Depending upon the type of system and the nature of the activity, it can sometimes be better to leave the server running until the client system no longer needs it. When the GUI is being used for interactive debugging, its behaviour is similar to that of a client. ( The server has internal safeguards that attempt to maintain an orderly environment in the computer. But that is extremely difficult from the server side and should not be depended upon. It is the client's responsibility to clean up after itself.)
Development Notes Both in production and development, the system configuration is important. The developer and system administrator must understand basic system configuration. CAUTION! CoreReader also has a job server and a command line interface. Do NOT enable them in a datasource server system. CoreReader also has autoconnect and autoquery capabilities. They can adversely effect server operations. They should be checked before running the data server. If CoreReader is installed in a multi-user configuration, and multiple servers are running against the same CoreReader database, each instance must enable the server and set the other configurations for the local instance instance. When running the server across the internet, careful thought should be given to the network type configuration. This is discused in the primary documentation. The system load sequence is:
The following may be used as a checklist when putting the server into production. These settings are not necessarily required by the server, but are recommended when they fit local needs. Multi-valued settings should be checked individually.
_________________________
Development Notes The commands and returns in the Datasource Server interface are the same for all languages and systems. The examples use the Ms. Visual Basic syntax because it is so widely known. The parentheses and quotes in these examples are not part of the server syntax. They are sometimes required by certain languages. The examples are not intended to be production-quality code, but all have been tested. The CoreReader GUI attempts to compensate for deviant database managers as a service to newcomers. The server does not do that. Also, the server will not alter SQL statements. Other than scanning for updates and DDL (see the security section), CoreReader ignores SQL passing through. All SQL language and dialect problems are the responsibility of the client and the database server.
Development Notes Create the object and load the system. We will use the sReturn variable to watch for any error messages that may be sent back to us from the CorePort.
dim o as object
First, the interface object was created as o. Then the object was told to load the server. After allowing time for system initialization, the above command has loaded CoreReader in server mode and it is waiting for commands. It will continue running until it is unloaded or until the computer is turned off.
Development Notes Connect to a data source using the specified connection. In this case, the name of the connection that was previously saved in CoreReader is a_test_connection.
sReturn = o . CoreConnect ( " a_test_connection " )
Development Notes Set the return type to an HTML table.
sReturn = o . CoreSetReturnType ( "html " )
Development Notes Run the specified saved query. ( Sometimes referred to as a stored procedure. ) In this case, the query was named a_query_name when it was previously saved in CoreReader.
sReturn = o . CoreRunQuery ( " a_query_name " )
Development Notes Execute the specified SQL statement.
sReturn = o . CoreRunSql ( "select * from tablename" )
Development Notes The time to retrieve a dataset from a remote server can sometimes be far greater than the rapid cycling of the local processor. The following is only one example of how one might compensate for that delay.
o . CoreSetReturnType ( "soap" )
Development Notes Read an HTML return from the CorePort into a variable.
sReturn = o . CoreRunSql ( "select * from tablename" )
Development Notes Unload, exit, shutdown. Everything stops.
sReturn = o . CoreUnloadServer
Development Notes Ignoring all errors, create the object, connect to a source, specify a dataset type of return, execute a saved query, display each record, and then unload.
dim o as object
_________________________ To make life easier for beginners, the CorePort appears to operate with only a single data connection. This is the default behavior. In this mode, making a new connection simply re-initializes everything for the new connection. All commands and returns automatically default to that connection. The CorePort also has multi-sourcing capability which allows it to maintain an unlimited number of simultaneous connections to data sources. When in the multi-source mode, the system is not initialized. When each connection is made to a source, the source's database is loaded. Thus, when in multi-source mode, the CoreReader server can appear as an unlimited number of databases, and queries can be run against all of them. When running in multi-source mode, the connection number must be specified for queries as shown in the command section. The CoreMultiSourceMode command switches to the multi-source mode. After switching to this mode, that will remain the mode of operation until the session ends. When a client puts CoreReader into multi-source mode, it is the responsibility of the client to keep track of the open sources. All of the sources are available for queries at all times. Data sources cannot be joined. If a virtual database is required, please see the AxleBase project at http://www.AxleBase.com/ in which a virtual database is being developed. The number of sources to which the system is currently connected can be found with the CoreSourceCount command.
_________________________
Development Notes The system that you have is not designed for multiple client service. Although multiple clients can run against it, it may not operate properly. In a multiple client environment, the CorePort server is serving more than one system. The clients may all run simultaneously at all times, or they may come and go. The multi-source mode is independent of the multi-client factor. Multi-source mode may be enabled or disabled regardless of the number of clients being served.
Development Notes A requirement of the standard CoreReader system is for it to be able to run on all types of systems, including old single-processor computers running Ms. Windows 95. That requirement prevents the standard CoreReader from being able to handle multi-threaded operations and, therefore, multiple clients. The standard issue CoreReader is designed to serve one client at a time. It is possible for multiple clients to simultaneously use the standard CoreReader, but that is unsafe and not recommended. If multi-client operation is needed, please notify admin @ corereader . com. A specially compiled multi-threaded CoreReader can be provided. The specially compiled multi-threaded CoreReader must be run on a server operating system which can handle multi-threaded systems. For such a heavy operation, it is recommended that the administrator also consider running it on a multi-processor computer.
Development Notes The multi-threaded CoreReader will assign each new client to a new thread and each thread to a processor if another processor is available. Up to ten clients may be served. More may be served, but this is not recommended. Ideally, there should be no more than one consumer per processor.
The basic GUI driven CoreReader operates as a single instance with one set of configurations, connections, etc. This has the advantage of easily managing a multi-node community. The administrator can load the GUI and easily configure the entire CoreReader installation. The disadvantage is that the CoreReader server configuration must be centrally managed. For example, multi-source mode control can be critical in a multi-node environment. Notice that when combined with the stimulating results of poor multi-source control, poor client control may be worthy of admission fees as a spectator sport.
_________________________ The use of the CoreReader server provides an additional layer of security to an organization while simplifying data access. The administrator can use the following features to design that enhanced security.
Development Notes When CoreReader is installed, it automatically disables the server interface. It may be enabled by changing the toggle in the system configuration screen. While the toggle is set to disabled, no error messages are returned to the calling system, and all attempts to access the server fail silently. To enable the server operation, press the tools button to display the advanced tools screen, then press the configuration button to display configuration screen. In the configuration screen, click on the server option, which will display the server panel. In the server panel, change the server toggle to "enabled". Servers on multiple computers can share a central CoreReader database (see the advanced documentation), but each server will have its own set of parameters stored in the database, so each server must have this toggle turned on.
Development Notes The configurations include a toggle for free form SQL statements. When the toggle is set to no, the server will not accept a SQL statement, and only saved queries (stored procedures) can be executed. When it is set to yes, free-form SQL statements will be accepted and executed. When CoreReader is installed, its security automatically sets this toggle to no. So the default is to deny SQL statements. While the toggle is set to no, error messages are not returned to the calling system, and all SQL statement queries fail silently. To enable free-form SQL statements, press the tools button to display the advanced tools screen, then press the configuration button to display configuration screen. In the configuration screen, click on the server option, which will display the server panel. In the server panel, change the toggle to "yes". Servers on multiple computers can share a central CoreReader database (see the advanced documentation), but each server will have its own set of parameters stored in the database, so each server must have this toggle turned on.
Development Notes The configurations include a toggle for SOAP control. When the toggle is set to no, the server will not accept SOAP transmissions. When it is set to yes, it will accept commands and queries via SOAP. When commands and queries are received via SOAP, they are extracted from the envelope and then go through the same mechanisms that control and run the listed commands. When CoreReader is installed, its security automatically sets this toggle to no. So the default is to deny SOAP. While the toggle is set to no, error messages are not returned to the calling system, and all SOAP transmissions fail silently. To enable this toggle, press the tools button to display the advanced tools screen, then press the configuration button to display configuration screen. In the configuration screen, click on the server option, which will display the server panel. In the server panel, change the toggle to "yes". Servers on multiple computers can share a central CoreReader database (see the advanced documentation), but each server will have its own set of parameters stored in the database, so each server must have this toggle turned on.
Development Notes The configurations include a toggle for free form SQL statements via SOAP. This setting is independent of the free-form SQL toggle. When this toggle is set to no, the server will not accept a SQL statement via SOAP, and only saved queries (stored procedures) can be executed via SOAP. When it is set to yes, SOAP may transmit free-form SQL statements. When queries are received via SOAP, they are extracted from the envelope and then go through the same mechanisms that control and run the other queries. When CoreReader is installed, its security automatically sets this toggle to no. So the default is to deny SQL statements via SOAP. While the toggle is set to no, error messages are not returned to the calling system, and all SQL statement queries received via SOAP transmissions fail silently. To enable this toggle, press the tools button to display the advanced tools screen, then press the configuration button to display configuration screen. In the configuration screen, click on the server option, which will display the server panel. In the server panel, change the toggle to "yes". Servers on multiple computers can share a central CoreReader database (see the advanced documentation), but each server will have its own set of parameters stored in the database, so each server must have this toggle turned on.
Development Notes By design, CoreReader is not discoverable.
Development Notes CoreReader can be connected to data sources through the server interface only by using existing connections that are stored in CoreReader's library. This is by design for security. The connections must be requested by name. Before a connection to a data source can be used, it must be manually created from the interactive GUI. An entire library of connections can be made to any number of databases or data sources that are owned by any number of brand name servers, spread sheets, etc. By design, the names of open data sources are not discoverable. When multiple sources are being kept open, the client systems must keep track of them. System security can also be enhanced by limiting the connections. If the multiple connection option is not turned on, then only a single connection can be maintained. When a new connection is made, since only a single connection is enabled, the new connection replaces the old one.
Development Notes The original CoreReader was designed to fail all SQL update and DDL commands. Large companies subsequently have started selling similar products which allow updates, so the internal safeguards have been removed to allow CoreReader to execute SQL update and DDL commands. The installation default allows update queries. If the "Allow Updates" parameter is changed to no, the fundamental query mechanism within CoreReader will fail all SQL update commands. Only queries will be permitted. Queries that come through the server interface will then be routed through an extensive audit mechanism that watches for updates. If the update ability is turned off and an update command is detected in a SQL statement, an error message is returned and the event is logged. The log entry includes the entire SQL statement. If the system is shared on a network, the log entry also includes the source. Since the GUI must update its database and since it runs through the server, the astute reader may be wondering if it is possible for a hacker to somehow use the GUI update mechanism. The GUI runs its own instance of AxleBase to manage its database operations. This isolates all update mechanisms inside the GUI and away from the server. There is no interface into the GUI and when it shuts down, it takes the update ability with it.
Development Notes Remote access to the CorePort server is not permitted. All activity must come from within the server's host operating system. A multi-user network installation is permitted where multiple users and servers share the same CoreReader database. This does not allow the server to be seen on the network. Remote access ports are easily created by web servers and other types of client systems. The additional security measures required by that type of installation are the responsibility of those who create it.
Development Notes The system design assumes that the host computer will be physically isolated and secure. Outside agencies must not be able to access the disk drive. The CoreReader database residing on the disk may contain sensitive material which must be safeguarded. For example, connections will contain required passwords and saved queries will contain metadata clues. The log also resides on disk, and it may be required to audit activity.
Development Notes If the infrastructure can stand the additional load, logging should be turned on when the server is enabled. Just turning on logging captures a minimal amount of activity, so verbose logging should also be turned on. Some of the things that an administrator can use in the log:
The log uses ragandate entries which are sixteen digit integers.
Development Notes By design, data source descriptions are not available from the server. Source and connection information within CoreReader is shielded. A detailed description of each dataset is made available to the server interface. However, that metadata is limited entirely to the current dataset. CoreReader is capable of running against views and saved queries (also known as stored procedures). When he loads a data source, he loads any views and visible queries into his table objects. Therefore, if additional shielding is required, CoreReader can be run against masking views and saved queries instead of the terminal data. Also, connections can be designed to shield the nature of their data sources. The connection can be limited by login rights and it can be limited to specific objects. ( This capability varies by data source. ) When CoreReader is used to create and save queries, all data can be aliased before delivery. The metadata available to the server will then be the aliased metadata. Finally, the administrator may use all or any combination of those features.
Development Notes The CoreReader system is designed to crash. Yes, designed that way. It makes no apologies; when overloaded, it either clears and recovers, or it crashes. Therefore, an attack on the system in the form of buffer overloading might crash the computer on which it runs in order to maintain security. System administrators should take note. However, an overload should not breach security. The most frequent overload failure is from simply requesting too much data in a query. System developers and system administrators should do all possible to safeguard against overwhelmingly large datasets. Overloading by creating an abnormally large number of data connections is prevented by the setting in the configurations. Administrators should insure that it is set properly for the computer on which the server runs. Administrators should be familiar with the data sockets that they use. An enterprise level CoreReader server uses a multitude of data sockets, all of which love to chat across any network that they can see with whomever will listen. CoreReader cannot control them or other external systems. Additional security can be given to a stand-alone CoreReader installation by excising the CorePort interface. Unregister it and delete it. CoreReader's basic operations will not be harmed, but the server will not be available to external apps. By design, the CorePort services are not discoverable via SOAP or web services.
__________________________________________________ Chapter API Lexicon And Syntactical Reference __________________________________________________ Syntax may be slightly altered by the requirements of a language or situation. The following specification is a generalized format. Parentheses and/or quotation marks are not required by the API and are used only for clarity. Their need will be dictated by the language and the situation. The return variables are not required. They are shown only to emphasize the fact that the commands are also functions. The general syntactical construct is:
Again, a particular language may require a slightly different syntactical construct, and certain situations may alter the requirements. ( API - Application Programming Interface )
_________________________ Syntax:
Return expected: None.
Tells CoreReader to close the specified connection. Where n is the identifying index number. If n is zero (0), then all connections are closed. Also tells CoreReader to destroy that connection's internal object to reclaim system resources. (See CoreInitialize.)
_________________________ Syntax:
Return expected: None.
Tells CoreReader to close the currently open dataset object. Also tells CoreReader to destroy the dataset's internal object to reclaim system resources. This command works regardless of the type of return. (See CoreInitialize.)
_________________________ Syntax:
Return expected: The contents of the column.
Returns the contents of the specified column. The column may be specified by its name or by its position in the tuple. ( Again, element number one is one; not number zero.) The tuple number is optional. If the tuple number is not passed, and the current cursor index is greater than zero (0), then the current tuple is red. If it is not passed and the Cursor is zero (0), then the first tuple is red. An empty data set raises a trappable error.
_________________________ Syntax:
Return expected: Number of columns in the set.
Returns the number of columns that were retrieved in the data set. If no data was returned in the data set, this returns a zero (0) column count.
_________________________ Syntax:
Return expected: The column name.
Returns the name of the column at the specified position. An undefined column raises a trappable error. It is defined when a dataset is created.
_________________________ Syntax:
Return expected: The numeric starting position.
Either a name or position number may be used to specify the column. This command may be useful when retrieving the entire tuple with the tuple command. An undefined column raises a trappable error. It is defined when a dataset is created.
_________________________ Syntax:
Return expected: The column data type.
Either a name or position number may be used to specify the column. An undefined column raises a trappable error. It is defined when a dataset is created.
_________________________ Syntax:
Return expected: The width of the column.
Either a name or position number may be used to specify the column. This command may be useful when retrieving the entire tuple with the tuple command. An undefined column raises a trappable error. It is defined when a dataset is created. Caution: Various brands of data sources define some special data types as a zero length because they are indeterminate.
_________________________ Syntax:
Return expected: Connection number.
Executes the specified stored connection. A successful connection returns an integer that specifies the index number of the connection. This is the number that will be used to specify which connection to use for queries. If the return is not numeric, it contains an error message. It is by intent that connections to sources can be made only with stored connections. See the Security Issues section for a discussion.
_________________________ Syntax:
Return expected: The legal copyright.
Do not attempt to mask, bypass, alter, alias, camouflage, or qualify either this command or its return. Such action immediately revokes the license for the individual and/or organization to use the system and may precipitate legal consequences. Although the license requires no unsolicited recognition, it requires that CoreReader be publicly recognized upon demand or inquiry and that the copyright and license accompany that information. Inquiries include any attempts to run this command to access its information.
_________________________ Syntax:
Return expected: The current tuple number.
Returns the current cursor location in the data set. This is the current cursor index number. By design, a cursor location is not automatically set. The host app must set it by using the navigation commands. This returns zero (0) if the cursor has not been set by the host app or if the dataset is empty.
_________________________ Syntax:
Return expected: Nothing.
Sets the server state to that in which it loaded. If initializeOnlyDataset is true, the initialization will include the current data set, metadata, and all parameters that can be set through this interface except the return type, but the connections will remain open. If initializeOnlyDataset is false, the connections will also be initialized. InitializeOnlyDataset is optional and the default is false. Before commanding an initialization execution, be sure that nothing is executing in the server and that no other clients are engaged in a conversation with it. If an error is returned from this command, the initialization may have been partial which would have left the server in an inconsistent state. If it is in an inconsistent state, it must be successfully initialized or reloaded. (See CoreCloseConnection and CoreCloseDataset.)
_________________________ Syntax:
Return expected: true or false
Returns the string "true" if the server is running, or "false" if it is not running.
_________________________ Syntax:
Return expected: The software license.
Returns the software licensing agreement to which the creator and user agreed. The return is approximately four thousand bytes of formatted text containing ASCII characters ten and thirteen for line feeds and carriage returns. Do not attempt to mask, bypass, alter, alias, camouflage, or qualify either this command or its return. Such action immediately revokes the license for the individual and/or organization to use CoreReader and may precipitate legal consequences. Alteration of the return is limited to the replacement of ASCII characters ten and thirteen, and only if such replacement is required to properly display the return with the intended carriage returns and line feeds. Although the license requires no unsolicited recognition, it does require that CoreReader be publicly recognized upon demand or inquiry and that the copyright and license accompany that information. Inquiries include any attempts to run this command to access its information.
_________________________ Syntax:
Return expected: None
Loads and initializes the CoreReader server.
_________________________ Syntax:
Return expected: The system release numbers.
The return is a formatted string in the form:
(See CoreVersion.)
_________________________ Syntax:
Return expected: A dataset object.
This feature is dangerous. It could even destroy systems. Simple warnings were considered, but programmers include a surplus of emotionally challenged people who would feel bound by the warning to use the feature. I would not mind, but such egos would then need to blame CoreReader for ensuing grief. Therefore, this feature will be made available only by special request. It will be made available only to senior level corporate development teams. ( Must be a team of senior level developers. ) When this value is set, CoreReader will create and return complete dataset objects without further processing. The advantage is a great increase in speed. The disadvantage is that the client assumes responsibility for all processing, error trapping, etc., which requires extensive knowledge of data sockets, data source brands and types, databases, etc. The CoreSetReturnType must specify this type.
_________________________ Syntax:
Return expected: The dataset.
Holds the data return if a return type other than the standard dataset type is requested. It is a stream of text, and the entire stream must be retrieved to get a valid return. If the dataset is empty, an error is not returned; an empty string is returned. However, data sources or other systems may insert error messages in their returns. See the CoreSetReturnType function for additional discussion.
_________________________ Syntax:
Return expected: None.
( This is still under study. The concept is viable, but its need is not yet determined. ) Runs the specified job which was previously saved in CoreReader's database. When this command is run, the server ignores the job's date and time. The advantage of this command is that the connection and query are specified in a single command. However, the system requires the same amount of time to perform them. Added to that time is the time required to look up and retrieve the job. A possible source of problems would be the setting of multi-source mode and then running jobs. Each time a job is run in that mode, another source will be created in the server. If the server is being kept alive, the sources would become unmanaged.
_________________________ Syntax:
Return expected: None
Runs the specified query ( stored procedure ) which was previously saved in CoreReader's database. Query failure raises an error message. The return of an empty dataset is not a query failure. The source number is optional to facilitate operation by beginners. It is a long integer and the default source is 1.
_________________________ Syntax:
Return expected: None
Runs the passed SQL statement. Query failure raises an error message. The return of an empty dataset is not a query failure. The source number is optional to facilitate operation by beginners. It is a long integer and the default source is 1. CoreReader audits SQL statements. See the Security Issues section. An attempt to frustrate security will return an error message. If the SQL toggle is off, this command fails silently. See the Security Issues section.
_________________________ Syntax:
Return expected: None
Not recommended for beginners. See the Multi-Sourced Operations section for a complete discussion of this command.
_________________________ Syntax:
Return expected: None
The first row of text type returns consists of the column headers. This toggle will turn that feature off and back on.
_________________________ Syntax:
Return expected: None
Changes the default column separator to the specified separator for text type returns.
_________________________ Syntax:
Return expected: None
Specifies a single protocol type to be used in constructing the return for subsequent queries. After the return type is set, it remains in effect for the session or until changed. ( All types of returns are used by the CoreReader GUI. ) Valid types are:
dataset Dataset returns a standard dataset and is the default. See the programming section for an example which retrieves a standard dataset. The various dataset handling commands are used to manipulate and retreive the data. XML When XML is specified, CoreReader uses the specified protocol to construct the dataset. The return is available through the CoreReturnStream function after completion of the query. It is delivered as a variable length unformatted data stream. HTML If an HTML return was specified before running the query, CoreReader knows that the requestor cannot or will not format a data set. Therefore, the entire dataset is framed in an HTML table for the return. This is only the table, so that it can immediately be included in a web page. The return is available through the CoreReturnStream function after completion of the query. It is delivered as a variable length unformatted data stream. SOAP The SOAP protocol precludes the return of errors that are generated within the protocol execution. Errors within the protocol are handled per protocol specification. The return is available through the CoreReturnStream function after completion of the query. It is delivered as a variable length unformatted data stream. Schemata appropriate to the following stream are in stream headers. text See also the CoreSetReturnColumnSeparator command. There are three text return commands; text, textfixedwidth, and textseparated. Text and textfixedwidth both return fixed width columns padded with blanks. CoreReader analyzes the data return to determine required widths. The widths may be the same as the data source storage width, or it may be determined by the data width, or CoreReader may set it according to the kind of data being returned. The textseparated returns contiguous columns with a separating character between the columns. ( Separated output is usually referred to as delimited, but the delimited nomenclature is misleading because the columns are not delimited. They are only separated by the special character. ) If you dislike textfixedwidth and textseparated, try something that you like and see if CoreReader agrees. Modified Hungarian, or underscores, or textdelimited, or upper case, or whatever. I have good reason for insisting on adherence to theoretical standards, but he does not always agree with me. rawDataObject This feature is dangerous. It could even destroy systems. Simple warnings were considered, but programmers include a surplus of emotionally challenged people who would feel bound by the warning to use the feature. I would not mind, but such egos would then need to blame CoreReader for their shortcomings. Therefore, this feature will be made available only by special request. It will be made available only to senior level corporate development teams. ( Must be a team of senior level developers. ) When this value is set, CoreReader will create and return complete dataset objects without further processing. The advantage is a great increase in speed. The disadvantage is that the client assumes responsibility for all processing, error trapping, etc., which requires extensive knowledge of data sockets, data source brands and types, databases, etc.
_________________________ Syntax:
Return expected: None.
( This command/function is still under construction. ) Note that this command is independent of the SOAP return that may be set by the coreSetReturnType. This command creates a complete SOAP interface. It passes a request or command to the server within the SOAP protocol. Error messages are returned within the SOAP protocol. By design, the CorePort services are not discoverable.
_________________________ Syntax:
Return expected: The number of open sources.
Returns the number of open sources to which connections are currently established. ( Please see the Multi-Source Operation section for details. ) An error return should not be confused with a count of zero.
_________________________ Syntax:
Return expected: The current tuple.
Returns an entire tuple without delimiters. Note that the tuple number is optional. If no tuple number is passed, and the cursor index is greater than zero, then it uses the current tuple. If no tuple is specified and the cursor index is zero, then the first tuple in the set is returned. ( Although it is not required, specifying the tuple number could be a good habit to develop. ) An empty dataset raises an error.
_________________________ Syntax:
Return expected: The number of tuples.
If no data was found, then this value is zero. Therefore, this is sometimes an ideal check for whether or not data was found.
_________________________ Syntax:
Return expected: None.
When this command is issued, the CoreReader server shuts down immediately. If the GUI is loaded, it will be unloaded. The developer should insure that all objects which he created are destroyed after the shutdown. The operating system may sometimes return an extraneous error message on an unload. It should be ignored. Only CoreReader, CorePort, and AxleBase errors are significant. ( Caution. See the Multi-Client section. )
_________________________ Syntax:
Return expected: The system version numbers.
The return is a formatted string in the form:
(See CoreRelease.)
_________________________ Syntax:
Return expected: None
A navigation command for moving the cursor through a data set. The cursor will move the specified number of rows from the current position. A trappable error is raised when the move is beyond either end of the set, or if there is no current position, or if the data set is empty.
_________________________ Syntax:
Return expected: None.
A navigation command for moving through a data set. This moves to the first record regardless of the current position or lack thereof. A trappable error is raised if the data set is empty.
_________________________ Syntax:
Return expected: None.
A navigation command for moving a cursor through a data set. This moves to the last record regardless of the current position or lack thereof. A trappable error is raised if the data set is empty.
_________________________ Syntax:
Return expected: None.
A navigation command for moving through a data set. This moves to the next record regardless of the current position. A trappable error is raised if the data set is empty, or the move is beyond an end of the set, or if there is no current position.
_________________________ Syntax:
Return expected: None.
A navigation command for moving a cursor through a data set. This moves to the previous record regardless of the current position. A trappable error is raised if the data set is empty, or the move is beyond an end of the set, or if there is no current position.
|
|
Technology and web site
|
|
|
Web site is maintained with Notepad.
|
|
