$Revision: 5240 $
Copyright 2002-2013 Fred Toussi. Permission is granted to distribute this document without any alteration under the terms of the HSQLDB license. Additional permission is granted to the HSQL Development Group to distribute this document with or without alterations under the terms of the HSQLDB license.
2013-07-08 15:32:59+0100
Table of Contents
HyperSQL Database (HSQLDB ) is a modern relational database system. Version 2.3 is the latest release of the all-new version 2 code. Written from ground up to follow the international ISO SQL:2011 standard, it supports the complete set of the classic features, together with optional features such as stored procedures and triggers.
HyperSQL is used for development, testing and deployment of database applications.
Standard compliance is the most unique characteristic of HyperSQL. There are several other distinctive features. HyperSQL can provide database access within the user's application process, within an application server, or as a separate server process. HyperSQL can run entirely in memory using dedicated fast memory structures as opposed to ram disk. HyperSQL can use disk persistence in a flexible way, with reliable crash-recovery. HyperSQL is the only open-source relational database management system with a high performance dedicated lob storage system, suitable for gigabytes of lob data. It is also the only relational database that can create and access large comma delimited files as SQL tables. HyperSQL supports three live switchable transaction control models, including fully multi threaded MVCC, and is suitable for high performance transaction processing applications. HyperSQL is also suitable for business intelligence, ETL and other applications that process large data sets. HyperSQL has a wide range of enterprise deployment options, such as XA transactions, connection pooling data sources and remote authentication.
New SQL syntax compatibility modes have been added to HyperSQL. These modes allow a high degree of compatibility with several other database systems which use non-standard SQL syntax.
HyperSQL is written in the Java programming language and runs in a Java virtual machine (JVM). It supports the JDBC interface for database access.
An ODBC driver is also available as a separate download.
This guide covers the database engine features, SQL syntax and different modes of operation. The Server, JDBC interfaces, pooling and XA components are documented in the JavaDoc. Utilities such as SqlTool and DatabaseManager are covered in a separate Utilities Guide.
The HSQLDB jar package, hsqldb.jar, is located in the /lib directory of the ZIP package and contains several components and programs.
Components of the Hsqldb jar package
HyperSQL RDBMS Engine (HSQLDB)
HyperSQL JDBC Driver
Database Manager (GUI database access tool, with Swing and AWT versions)
The HyperSQL RDBMS and JDBC Driver provide the core functionality. DatabaseManagers are general-purpose database access tools that can be used with any database engine that has a JDBC driver.
An additional jar, sqltool.jar, contains Sql Tool, command line database access tool. This is a general purpose command line database access tool that can be ued with other database engines as well.
The tools are used for interactive user access to databases,
including creation of a database, inserting or modifying data, or querying
the database. All tools are run in the normal way for Java programs. In
the following example the Swing version of the Database Manager is
executed. The hsqldb.jar
is located in the directory
../lib
relative to the current directory.
java -cp ../lib/hsqldb.jar org.hsqldb.util.DatabaseManagerSwing
If hsqldb.jar
is in the current directory, the
command would change to:
java -cp hsqldb.jar org.hsqldb.util.DatabaseManagerSwing
Main classes for the Hsqldb tools
org.hsqldb.util.DatabaseManager
org.hsqldb.util.DatabaseManagerSwing
When a tool is up and running, you can connect to a database (may be a new database) and use SQL commands to access and modify the data.
Tools can use command line arguments. You can add the command line argument --help to get a list of available arguments for these tools.
Double clicking the HSQLDB jar will start the DatabaseManagerSwing application.
Each HyperSQL database is called a catalog. There are three types of catalog depending on how the data is stored.
Types of catalog data
mem: stored entirely in RAM - without any persistence beyond the JVM process's life
file: stored in filesystem files
res: stored in a Java resource, such as a Jar and always read-only
All-in-memory, mem: catalogs can be used for test data or as sophisticated caches for an application. These databases do not have any files.
A file: catalog consists of between 2 to 6 files, all named the same but with different extensions, located in the same directory. For example, the database named "test" consists of the following files:
test.properties
test.script
test.log
test.data
test.backup
test.lobs
The properties file contains a few settings about the database. The
script file contains the definition of tables and other database objects,
plus the data for non-cached tables. The log file contains recent changes
to the database. The data file contains the data for cached tables and the
backup file is a compressed backup of the last known consistent state of
the data file. All these files are essential and should never be deleted.
For some catalogs, the test.data
and
test.backup
files will not be present. In addition to
those files, a HyperSQL database may link to any formatted text files,
such as CSV lists, anywhere on the disk.
While the "test" catalog is open, a test.log
file is used to write the changes made to data. This file is removed at a
normal SHUTDOWN. Otherwise (with abnormal shutdown) this file is used at
the next startup to redo the changes. A test.lck
file
is also used to record the fact that the database is open. This is deleted
at a normal SHUTDOWN.
| Note | |
|---|---|
|
When the engine closes the database at a shutdown, it creates
temporary files with the extension |
A res: catalog consists of the files for a small, read-only database that can be stored inside a Java resource such as a ZIP or JAR archive and distributed as part of a Java application program.
In general, JDBC is used for all access to databases. This is done
by making a connection to the database, then using various methods of the
java.sql.Connection
object that is returned to
access the data. Access to an in-process database
is started from JDBC, with the database path specified in the connection
URL. For example, if the file: database name is
"testdb" and its files are located in the same directory as where the
command to run your application was issued, the following code is used for
the connection:
Connection c = DriverManager.getConnection("jdbc:hsqldb:file:testdb", "SA", "");
The database file path format can be specified using forward slashes
in Windows hosts as well as Linux hosts. So relative paths or paths that
refer to the same directory on the same drive can be identical. For
example if your database directory in Linux is /opt/db/
containing a database testdb (with files named testdb.*), then the
database file path is /opt/db/testdb.
If you create an
identical directory structure on the C:
drive of a
Windows host, you can use the same URL in both Windows and Linux:
Connection c = DriverManager.getConnection("jdbc:hsqldb:file:/opt/db/testdb", "SA", "");
When using relative paths, these paths will be taken relative to the
directory in which the shell command to start the Java Virtual Machine was
executed. Refer to the Javadoc for JDBCConnection
for more
details.
Paths and database names for file databases are treated as case-sensitive when the database is created or the first connection is made to the database. But if a second connection is made to an open database, using a path and name that differs only in case, then the connection is made to the existing open database. This measure is necessary because in Windows the two paths are equivalent.
A mem: database is specified by the mem: protocol. For mem: databases, the path is simply a name. Several mem: databases can exist at the same time and distinguished by their names. In the example below, the database is called "mymemdb":
Connection c = DriverManager.getConnection("jdbc:hsqldb:mem:mymemdb", "SA", "");
A res: database, is specified by the res: protocol. As it is a Java resource, the database path is a Java URL (similar to the path to a class). In the example below, "resdb" is the root name of the database files, which exists in the directory "org/my/path" within the classpath (probably in a Jar). A Java resource is stored in a compressed format and is decompressed in memory when it is used. For this reason, a res: database should not contain large amounts of data and is always read-only.
Connection c = DriverManager.getConnection("jdbc:hsqldb:res:org.my.path.resdb", "SA", "");
The first time in-process connection is made to a database, some general data structures are initialised and a few helper threads are started. After this, creation of connections and calls to JDBC methods of the connections execute as if they are part of the Java application that is making the calls. When the SQL command "SHUTDOWN" is executed, the global structures and helper threads for the database are destroyed.
Note that only one Java process at a time can make in-process connections to a given file: database. However, if the file: database has been made read-only, or if connections are made to a res: database, then it is possible to make in-process connections from multiple Java processes.
For most applications, in-process access is faster, as the data is not converted and sent over the network. The main drawback is that it is not possible by default to connect to the database from outside your application. As a result you cannot check the contents of the database with external tools such as Database Manager while your application is running.
Server modes provide the maximum accessibility. The database engine runs in a JVM and opens one or more in-process catalogs. It listens for connections from programs on the same computer or other computers on the network. It translates these connections into in-process connections to the databases.
Several different programs can connect to the server and retrieve or update information. Applications programs (clients) connect to the server using the HyperSQL JDBC driver. In most server modes, the server can serve an unlimited number of databases that are specified at the time of running the server, or optionally, as a connection request is received.
A Sever mode is also the preferred mode of running the database during development. It allows you to query the database from a separate database access utility while your application is running.
There are three server modes, based on the protocol used for communications between the client and server. They are briefly discussed below. More details on servers is provided in the HyperSQL Network Listeners (Servers) chapter.
This is the preferred way of running a database server and the fastest one. A proprietary communications protocol is used for this mode. A command similar to those used for running tools and described above is used for running the server. The following example of the command for starting the server starts the server with one (default) database with files named "mydb.*" and the public name of "xdb". The public name hides the file names from users.
java -cp ../lib/hsqldb.jar org.hsqldb.server.Server --database.0 file:mydb --dbname.0 xdb
The command line argument --help
can be used to
get a list of available arguments.
This method of access is used when the computer hosting the database server is restricted to the HTTP protocol. The only reason for using this method of access is restrictions imposed by firewalls on the client or server machines and it should not be used where there are no such restrictions. The HyperSQL HTTP Server is a special web server that allows JDBC clients to connect via HTTP. The server can also act as a small general-purpose web server for static pages.
To run an HTTP server, replace the main class for the server in the example command line above with the following:
org.hsqldb.server.WebServer
The command line argument --help
can be used to
get a list of available arguments.
This method of access also uses the HTTP protocol. It is used when
a separate servlet engine (or application server) such as Tomcat or
Resin provides access to the database. The Servlet Mode cannot be
started independently from the servlet engine. The
Servlet
class, in the HSQLDB jar, should be
installed on the application server to provide the connection. The
database file path is specified using an application server property.
Refer to the source file
src/org/hsqldb/server/Servlet.java
to see the details.
Both HTTP Server and Servlet modes can be accessed using the JDBC driver at the client end. They do not provide a web front end to the database. The Servlet mode can serve multiple databases.
Please note that you do not normally use this mode if you are using the database engine in an application server. In this situation, connections to a catalog are usually made in-process, or using a separate Server
When a HyperSQL server is running, client programs can connect to
it using the HSQLDB JDBC Driver contained in
hsqldb.jar
. Full information on how to connect to a
server is provided in the Java Documentation for JDBCConnection
(located in the /doc/apidocs
directory of HSQLDB
distribution). A common example is connection to the default port (9001)
used for the hsql: protocol on the same
machine:
Example 1.1. Java code to connect to the local hsql Server
try { Class.forName("org.hsqldb.jdbc.JDBCDriver" ); } catch (Exception e) { System.err.println("ERROR: failed to load HSQLDB JDBC driver."); e.printStackTrace(); return; } Connection c = DriverManager.getConnection("jdbc:hsqldb:hsql://localhost/xdb", "SA", "");
If the HyperSQL HTTP server is used, the protocol is http: and the URL will be different:
Example 1.2. Java code to connect to the local http Server
Connection c = DriverManager.getConnection("jdbc:hsqldb:http://localhost/xdb", "SA", "");
Note in the above connection URL, there is no mention of the database file, as this was specified when running the server. Instead, the public name defined for dbname.0 is used. Also, see the HyperSQL Network Listeners (Servers) chapter for the connection URL when there is more than one database per server instance.
When a HyperSQL server is run, network access should be adequately protected. Source IP addresses may be restricted by use of our Access Control List feature, network filtering software, firewall software, or standalone firewalls. Only secure passwords should be used-- most importantly, the password for the default system user should be changed from the default empty string. If you are purposefully providing data to the public, then the wide-open public network connection should be used exclusively to access the public data via read-only accounts. (i.e., neither secure data nor privileged accounts should use this connection). These considerations also apply to HyperSQL servers run with the HTTP protocol.
HyperSQL provides two optional security mechanisms. The encrypted SSL protocol, and Access Control Lists. Both mechanisms can be specified when running the Server or WebServer. On the client, the URL to connect to an SSL server is slightly different:
Example 1.3. Java code to connect to the local secure SSL hsql and http Servers
Connection c = DriverManager.getConnection("jdbc:hsqldb:hsqls://localhost/xdb", "SA", ""); Connection c = DriverManager.getConnection("jdbc:hsqldb:https://localhost/xdb", "SA", "");
The security features are discussed in detail in the HyperSQL Network Listeners
(Servers)
chapter.
A server can provide connections to more than one database. In the
examples above, more than one set of database names can be specified on
the command line. It is also possible to specify all the databases in a
.properties
file, instead of the command line. These
capabilities are covered in the HyperSQL Network Listeners
(Servers) chapter
As shown so far, a java.sql.Connection
object
is always used to access the database. But the speed and performance
depends on the type of connection.
Establishing a connection and closing it has some overheads, therefore it is not good practice to create a new connection to perform a small number of operations. A connection should be reused as much as possible and closed only when it is not going to be used again for a long while.
Reuse is more important for server connections. A server connection uses a TCP port for communications. Each time a connection is made, a port is allocated by the operating system and deallocated after the connection is closed. If many connections are made from a single client, the operating system may not be able to keep up and may refuse the connection attempt.
A java.sql.Connection
object has some methods
that return further java.sql.*
objects. All these
objects belong to the connection that returned them and are closed when
the connection is closed. These objects can be reused, but if they are not
needed after performing the operations, they should be closed.
A java.sql.DatabaseMetaData
object is used to
get metadata for the database.
A java.sql.Statement
object is used to
execute queries and data change statements. A
java.sql.Statement
can be reused to execute a
different statement each time.
A java.sql.PreparedStatement
object is used
to execute a single statement repeatedly. The SQL statement usually
contains parameters, which can be set to new values before each reuse.
When a java.sql.PreparedStatement
object is
created, the engine keeps the compiled SQL statement for reuse, until the
java.sql.PreparedStatement
object is closed. As a
result, repeated use of a
java.sql.PreparedStatement
is much faster than
using a java.sql.Statement
object.
A java.sql.CallableStatement
object is used
to execute an SQL CALL statement. The SQL CALL statement may contain
parameters, which should be set to new values before each reuse. Similar
to java.sql.PreparedStatement
, the engine keeps the
compiled SQL statement for reuse, until the
java.sql.CallableStatement
object is closed.
A java.sql.Connection
object also has some
methods for transaction control.
The commit()
method performs a
COMMIT
while the rollback()
method performs a ROLLBACK
SQL statement.
The setSavepoint(String name)
method
performs a SAVEPOINT <name>
SQL statement and
returns a java.sql.Savepoint
object. The
rollback(Savepoint name)
method performs a
ROLLBACK TO SAVEPOINT <name>
SQL
statement.
The Javadoc for
JDBCConnection
,
JDBCDriver
,
JDBCDatabaseMetadata
JDBCResultSet
,
JDBCStatement
,
JDBCPreparedStatement
list all the supported JDBC methods
together with information that is specific to HSQLDB.
All databases running in different modes can be closed with the SHUTDOWN command, issued as an SQL statement.
When SHUTDOWN is issued, all active transactions are rolled back. The catalog files are then saved in a form that can be opened quickly the next time the catalog is opened.
A special form of closing the database is via the SHUTDOWN COMPACT
command. This command rewrites the .data
file that
contains the information stored in CACHED tables and compacts it to its
minimum size. This command should be issued periodically, especially when
lots of inserts, updates or deletes have been performed on the cached
tables. Changes to the structure of the database, such as dropping or
modifying populated CACHED tables or indexes also create large amounts of
unused file space that can be reclaimed using this command.
Databases are not closed when the last connection to the database is
explicitly closed via JDBC. A connection property,
shutdown=true
, can be specified on the first connection
to the database (the connection that opens the database) to force a
shutdown when the last connection closes.
Example 1.4. specifying a connection property to shutdown the database when the last connection is closed
Connection c = DriverManager.getConnection( "jdbc:hsqldb:file:/opt/db/testdb;shutdown=true", "SA", "");
This feature is useful for running tests, where it may not be
practical to shutdown the database after each test. But it is not
recommended for application programs.
When a server instance is started, or when a connection is made to an in-process database, a new, empty database is created if no database exists at the given path.
With HyperSQL 2.0 the username and password that are specified for the connection are used for the new database. Both the username and password are case-sensitive. (The exception is the default SA user, which is not case-sensitive). If no username or password is specified, the default SA user and an empty password are used.
This feature has a side effect that can confuse new users. If a
mistake is made in specifying the path for connecting to an existing
database, a connection is nevertheless established to a new database. For
troubleshooting purposes, you can specify a connection property
ifexists=true
to allow connection
to an existing database only and avoid creating a new database. In this
case, if the database does not exist, the
getConnection()
method will throw an
exception.
Example 1.5. specifying a connection property to disallow creating a new database
Connection c = DriverManager.getConnection( "jdbc:hsqldb:file:/opt/db/testdb;ifexists=true", "SA", "");
A database has many optional properties, described in the System Management chapter. You can specify most of these properties on the URL or in the connection properties for the first connection that creates the database. See the Properties chapter.
$Revision: 5206 $


areaDetector ADSC driver
August 9, 2011
Lewis Muir
University of Chicago
Table of Contents
- Introduction
- Dependencies
- Building
- Configuring
- Image Modes
- Trigger Modes
- Dark Images
- Driver Specific Values and Settings
- Screenshots
- Unsupported areaDetector
base
Features
- Limitations
Introduction
This is an EPICS
areaDetector
driver for ADSC detectors. Supported
models are: Q4 (with the upgrade to four computers), Q4r, Q210, Q210r, Q270, Q315,
and Q315r. This driver has been tested with the Q210 and Q210r. If you use this
driver, please report your success, noting your detector model, to the author.
Dependencies
This driver controls the detector via the detcon_lib_th detector control
library provided by ADSC. The detcon_lib_th library must date from 2008-06-30
or newer.
Building
By default, this driver is built against a simulated control library. To build against
the ADSC detcon_lib_th control library to control a real detector, follow
these steps:
- Build the ADSC auxlib library provided by ADSC
- Build the ADSC detcon_lib_th library provided by ADSC
- Copy and rename, or create a symlink to, the ADSC auxlib.a library so
that it has the name libauxlib.a to satisfy the EPICS build facility's
requirement that a library file name start with
lib
- Set USE_SIMADSC to NO in ADApp/adscSrc/Makefile
- Set ADSC_HOME in ADApp/adscSrc/Makefile
- Rebuild the areaDetector module
Configuring
This driver is configured via the adscConfig() function. If this is to
be used in an IOC, it must be called before iocInit(). It has the following
signature:
- int adscConfig(const char *portName, const char *modelName)
-
- portName
-
ASYN port name for the driver instance
- modelName
-
ADSC detector model name; must be one of Q4, Q4r, Q210,
Q210r, Q270, Q315, Q315r
The underlying ADSC control library obtains its configuration from the environment.
Therefore, the environment must be correctly configured (i.e. ADSC environment variables
set) for the ADSC control library before calling adscConfig().
If being used in an IOC, and an EPICS PV interface with the driver is desired, the
ADBase.template, NDFile.template, and adsc.template databases
should also be loaded for the driver instance.
There is an example IOC boot directory and startup script (iocBoot/iocAdsc/st.cmd)
provided with areaDetector.
Image Modes
Single
The Single mode acquires just one image.
Multiple
The Multiple mode acquires the number of images specified in $(P)$(R)NumImages_RBV.
Continuous
The Continuous mode acquires images indefinitely until last image
is set. In this mode, the last image of the acquisition must be signaled before
exposing the last image by setting $(P)$(R)ADSCLastImage to 1.
This requirement is due to how the underlying ADSC control library works.
Trigger Modes
Internal
The Internal mode will make the driver expose images on its own once the
acquisition is started.
Ext. Software
The Ext. Software mode will make the driver expose images only when told
to once the acquisition is started. A special protocol must be followed to trigger
each image exposure. This would normally be very simple, but because the ADSC control
library can report that an exposure did not work and should be retried after any
exposure, a more complex protocol is required.
The protocol is described in terms of the EPICS PV driver interface, but the same
rules apply if controlling the driver directly through ASYN. The protocol is as
follows:
- Wait for $(P)$(R)ExSwTrOkToExp to be Yes
- Set $(P)$(R)ExSwTrCtl to Start to start the exposure
- Set $(P)$(R)ExSwTrCtl to Stop to stop the exposure
- Wait for $(P)$(R)ExSwTrCtlRsp to be OK or Again
- If $(P)$(R)ExSwTrCtlRsp is Again, the exposure did not work
and should be tried again
Note that care must be taken when waiting for $(P)$(R)ExSwTrCtlRsp to be
OK or Again to ensure the PV value is not stale (i.e. from the
previous exposure). There are at least two methods to ensure this:
- Use a CA monitor on $(P)$(R)ExSwTrCtlRsp; before waiting for the
OK or Again values, wait for the Stop value; a CA monitor
is used to receive the value changes since the PV will have the Stop value
for just a short time
- After starting the exposure, wait for $(P)$(R)ExSwTrCtlRsp to be
Start
Dark Images
Dark images are acquired automatically at the beginning of a data acquisition. They
are taken if any of the following conditions are true:
- Reuse darks is No
- Exposure time is different from that of the previous acquisition
- ADC/binning is different from that of the previous acquisition
- Binning is different from that of the previous acquisition
- The acquisition is the first after stored darks was changed from
Yes to No
Driver Specific Values and Settings
This driver provides status values and settings in addition to what is provided
by areaDetector base
. They are listed here according to their label
in the driver specific MEDM GUI and their EPICS PV name in the EPICS PV driver interface.
A screenshot of the driver specific MEDM GUI can be seen in the
Screenshots section.
Detector Condition
- State, $(P)$(R)ADSCState
-
State of the detector reported by the ADSC control library.
- Status, $(P)$(R)ADSCStatus
-
Status message reported by the ADSC control library.
- Last error, $(P)$(R)ADSCLastError
-
Last error message reported by the ADSC control library.
- Update rate for above properties, $(P)$(R)ADSCReadConditn.SCAN
-
How frequently to update the above properties.
Detector Error Recovery
- Software Reset, $(P)$(R)ADSCSoftReset
-
Performs a software reset. Aborts any current operation, clears status and error
messages, and sets detector state to Idle.
Detector Continuous Image Mode
- Last Image, $(P)$(R)ADSCLastImage
-
Signals that the next exposure is the last image when in Continuous image
mode.
Detector External Software Trigger
- OK to expose, $(P)$(R)ExSwTrOkToExp
-
When in Ext. Software trigger mode, indicates whether it is OK to start
an image exposure.
- Start, Stop, $(P)$(R)ExSwTrCtl
-
When in Ext. Software trigger mode, set to 1 to start an exposure,
and set to 0 to stop it.
- $(P)$(R)ExSwTrCtlRsp
-
When in Ext. Software trigger mode, will be Start, Stop,
OK, or Again. See Trigger Modes section
for more about how this property will behave.
Driver Parameters
- Reuse darks, $(P)$(R)ADSCReusDrk
-
Reuse dark images when possible. This is useful to avoid wasting time acquiring
dark images when previously acquired dark images are available and can be reused.
- Dezinger, $(P)$(R)ADSCDezingr
-
Acquire
dezingered
images.
Detector Hardware Parameters
- ADC/Binning, $(P)$(R)ADSCAdc
-
For Q4 and Q4r detectors, controls whether to use Fast or Slow
ADC. For all other detectors, controls whether to use Hardware or Software
binning.
- Raw images, $(P)$(R)ADSCRaw
-
Write raw images.
- Image transforms, $(P)$(R)ADSCImXform
-
Perform image transformations.
- Stored darks, $(P)$(R)ADSCStrDrks
-
Use stored dark images. If set to Yes, stored dark images are assumed to
have been installed by ADSC and should be used.
Detector File Parameters
- Beam center X, $(P)$(R)ADSCBeamX
-
Beam center in the X dimension.
- Beam center Y, $(P)$(R)ADSCBeamY
-
Beam center in the Y dimension.
- Distance, $(P)$(R)ADSCDistnce
-
Detector distance.
- Two theta, $(P)$(R)ADSC2Theta
-
Detector 2θ angle.
- Axis, $(P)$(R)ADSCAxis
-
Crystal rotation axis.
- Wavelength, $(P)$(R)ADSCWavelen
-
X-ray wavelength.
- Image width, $(P)$(R)ADSCImWidth
-
Crystal rotation during exposure.
- Phi, $(P)$(R)ADSCPhi
-
Phi position at start of exposure.
- Omega, $(P)$(R)ADSCOmega
-
Omega position at start of exposure.
- Kappa, $(P)$(R)ADSCKappa
-
Kappa position at start of exposure.
Screenshots
Unsupported areaDetector base
Features
- Shutter control
- Collect: number of exposures per image
- File: save file
- File: read file
- File: format
- File: auto save (always Yes)
- Readout: image region of interest
- Readout: reverse image
- Readout: gain
- Readout: data type (always UInt16)
- Image frame callbacks
Limitations
- Only one ADSC detector may be controlled with this driver per OS process. If this
driver is being used in an IOC, this means only one ADSC detector may be controlled
with this driver per IOC. This is a limitation of the underlying ADSC control library
which does not support more than one detector per OS process.
- Acquiring
dezingered
images is not supported. This is a limitation of the
underlying ADSC control library which has a bug preventing it from working correctly.
- Software reset does not work. This is a limitation of the underlying
ADSC control library which has a bug preventing it from working correctly. It would
be great if, after an error, performing a software reset would allow a new acquisition
to proceed normally. Currently, the recovery solution often is to restart the control
software.


New tech puts virtual sense of touch at our fingertips
Paris: Garrett Anderson has never known the pleasure of holding hands with both his children at the same time.
While deployed in Iraq with the US army in 2005, a bomb blast shot shrapnel through his right arm, severing it just below the elbow.
Today, the Illinois-based retired veteran wears a prosthetic which allows him to pick up objects and have basic mobility.
But it cannot duplicate the sense of touch.
A new second-skin "virtual reality" technology -- designed to work with both prosthetics and gaming applications -- may change that.
The system, developed by researchers at Northwestern University and described in the journal Nature, incorporates 32 individually programmable actuators -- a device that emits electric impulses or vibrations -- which are embedded into a pliable material made from silicone that adheres to the skin.
Controlled by a wireless touchscreen such as a smartphone or tablet, each actuator -- the size of a small coin -- vibrates to create the perception of touch. The user can control the pressure and the pattern of the sensation.
Anderson tried the system, integrated with his prosthetic. While wearing a patch on his skin, he could feel sensations from his prosthetic fingertips transmitted to his arm.
Over time, the brain converts that sensation to what researcher John Rogers describes as a "surrogate sense of feeling".
'Emotional connection'
The authors say the device could also be used for social interactions, offering a stroke of an arm to a loved one during a video call, or a pat of encouragement to a teammate during a virtual game.
"Our sense of touch provides the most profound, deepest, emotional connection between people," Rogers said in a statement.
In the study, published Wednesday, the authors described a scenario in which a young girl touches her grandmother's hand during a video call.
"We are interested in fine touch -- a finger stroke across the arm or shoulder, or a pattern of sensation that can reproduce a surrogate of touch," Rogers told AFP.
The device is wireless and does not require battery power. It uses the same near-field communication protocols found in smartphone banking applications, such as Apple Pay.
"With this wireless power delivery scheme, we completely avoid the need for batteries, with their weight, size, bulk and limited operating lifetimes," Rogers said. "The result is a thin, lightweight system that can be worn and used without constraint, indefinitely."
'Deeply moving experience'
For Anderson, the technology may finally allow him to simultaneously clasp the hands of his children, aged 13 and 10.
But it will also have practical applications, such as being able to sense how much force he's applying when gripping a fragile object or touching someone.
"I remember when I was first injured, I grabbed my mom's hand and almost broke it because I did not know the amount of pressure I was using," Anderson told AFP.
Rogers said his aim is to improve quality of life, and that working with Anderson was "a deeply moving experience."
The prototype is only a first attempt, and researchers are working to make the device lighter and slimmer.
In the future, they would also like to explore thermal inputs, which will allow someone with a prosthetic hand to feel how hot or cold a drink is.
"When I explain to others how it works they are floored by what people are able to develop," Anderson said.
Read also
Read More
Disaster hacks: South American cities harness tech and nature to tackle flooding
Hit with ever-more-frequent torrential rain that triggers worsening flooding and mudslides most years, Rio de Janeiro is looking to an unusual gathering for answers: a hackathon.
Read More
Vestager gears up for tech czar role with warning over data
Margrethe Vestager, the European Union’s new tech czar, warned that privacy watchdogs must have resources to match their beefed-up powers and issued a fresh antitrust threat to companies abusing their control of data to crush competition.
Read More
Thai bank targets $1 billion spinoff among its fintech units
Siam Commercial Bank Pcl plans to spin off some of its fintech divisions as it tries to monetize its push into technology investment at a time of sluggish earnings from traditional lending.
Read More
Big tech - too big to fail, says data whistleblower Wylie
Big Tech is becoming "too big to fail" and should not saddle ill-equipped consumers with safekeeping privacy for society at large, data whistleblower Christopher Wylie said on Thursday.
Read More
Tech route to greener cities only 'smart' if residents follow
High-tech solutions to make cities greener already exist - from local clean power grids to electric transport hubs and intelligent buildings - but deploying them fast enough to curb climate change is a challenge, city and business officials said Wednesday.


Events sending interval. Default is 5000.
Number of buffer items to send in a request. Default is 2.
Maximum buffer capacity in Kilobytes. Default is 64Kb.
Retrying limit when sending events. Default is 15.
Maximum buffer items allowed. Default is 100. Max buffer item capacity = (maxBufferCapacityKb * 1024) / totalBufferItems;
Generated using TypeDoc
EventBufferConfiguration contains necessary information to configure buffer.


Additional Content
Frequently Asked:
Questions and Answers
It’s a digital ecosystem for national spatial planning that will enable sharing of spatial planning information and data across all spheres of government and will support key objectives of the SPLUMA and the NDP.
The national Department of Rural Development and Land Reform through its Spatial Planning and Land Use Management branch, are responsible for both the development and maintenance of the NSPDR ecosystem.
See our contact page for more information.
See our contact page for more information.
Not at all... municipalities will only be required to register themselves on the system. So once registered municipalities will have full access to the NSPDR ecosystem.
Project Information:
Documents and Legislation
Legislation
- Infrastructure Development Act (23 of 2014)
- Spatial Planning and Land Use Management Act (16 of 2013) *
- Protection of Personal Information Act (4 of 2013)
- Intergovernmental Relations Framework Act (13 of 2005)
- Spatial Data Infrastructure Act (54 of 2003)
- Municipal Systems Act (32 of 2000)
- Promotion of Access to Information Act (2 of 2000)
- Municipal Structures Act (117 of 1998)
- Expropriation Act (63 of 1975)
- Subdivision of Agricultural Land Act (70 of 1970)
- Deeds Registries Act (47 of 1937)


Setting Up a JDBC Resource on the Oracle iPlanet Web Server
See Also
A JDBC resource (data source) provides applications with a means of connecting to a database. Typically, there is at least one JDBC resource for each database accessed by an application deployed in a domain. It is possible to have more than one JDBC resource for a database.
To create a JDBC resource:
- Ensure the Oracle iPlanet Web Server is running.
- In the Projects window, select your project's root node to make it the active node and choose File > New File (Ctrl-N).
- In the Categories list, select Sun Web Server 7.0 Resources, in the File Types list, select JDBC Resource, then click Next.
- In the General Attributes page, in the General area, do the following:
- (required) Enter a unique JNDI name for the resource.
- When you register the resource with the server, if a resource already exists with the name you enter here, the existing resource will be updated with the attributes and properties of the resource you are registering.
- Enable or disable the resource by choosing True or False.
- From the Database Vendor drop-down list, select the database vendor and driver for the resource.
When you select a value from this drop-down list, the IDE fills in the next field, Data Source Class Name.
- Accept the value in the Data Source Class Name field or make changes to match your implementation.
- Enter a description.
- In the General Attributes page, in the Database Connection Settings area, make changes to suit your preferences.
- Click Next.
- In the Additional Properties page, enter any properties for the resource.
- Click Finish.
- Register the resource with the Oracle iPlanet Web Server.
- See Also
- Connecting to a Database
Copyright © 2006 Sun Microsystems, Inc. All rights reserved.
Legal Notices