The below list of Frequently Asked Questions (FAQs)
is constantly updated based on our customer's requests. As with any database interface,
NativeDB heavily relies on the quality of the lower database layers it communicates
with. We encourage you to re-check this list of known issues if you encounter any
problem or have questions not covered in our documentation.
|"While executing a long running query or DML statement in the main thread of my GUI application I sometimes get an 'application not resonding' message from Windows, freezing my application. Is it some way to avoid this from happing?"|
To avoid this you can write an TAsaSession.OnServerWait event. In the
event you should dispatch any incoming Windows messages and simply
remove them from the thread's message queue:
procedure TForm1.AsaDataset1ServerWait(Sender: TObject; var AbortRequest: Boolean); var Msg: TMsg; begin PeekMessage(Msg, 0, 0, 0, PM_REMOVE); end;
|"Using NativeDB Alerts, sometimes a few clients stops receiving incoming messages?"|
Every client using NativeDB Alerts consumes an extra thread/task at the
ASA server-side to handle receiving messages. Hence consider the -gn server
option to increase the number of tasks that the database server can handle
concurrently. The default value is 20. This can be to few if you have many
concurrently active clients. To our knowledge and experience a value
of 120 solves your issue.
|"I have a situation where I am distributing an application that is used on laptops/notebooks where the user suspends or hibernates the computer. A problem has arisen where the database connection is terminated/lost when the notebook restarts if it is left off for a longer period of time. Is there any known way to work around this problem?"|
We have experienced this problem in a few cases when the database
connection is based on local TCP. To work around the problem set the
TAsaSession.ClientParams property to "commlinks=shmem". This will force
ASA to use a local shared memory connection instead. For shared memory
connections, the only time the server ever disconnects the client is when
the client process terminates (i.e. the server can no longer find the
client process id in the list of running processes).
|"I can't determine how to set a database's name on startup. I'm establishing a workstation connection by starting up a database file (dbf) with dbeng6. The dbn defaults to the file's prefix, but I want to name it something else?"|
When specifying the database file using the TAsaSession.LoginDatabase property
only, ASA will by default name the database to the database file prefix.
To name it differently, the trick is to clear the LoginDatabase property and
instead specify the entire startup line explicitly in the TAsaSession.ServerParams
try AsaSession1.ClientParams := 'dbn=demo_db'; AsaSession1.LoginDatabase := '' AsaSession1.LoginEngineName := 'demo_db' AsaSession1.ServerParams := 'start=dbeng6.exe "C:\Asa6\asademo.db" -n demo_db' AsaSession1.ServerType := stServer; AsaSession1.Connected := True; except on E: EAsaException do ShowMessage(E.Message); end;These settings will start the database file 'asademo.db' and name it 'demo_db'. The database engine (eng) itself will by default be named 'demo_db' too. If you even want to name the engine differently, you need to include another -n switch before the first database file is specified.
AsaSession1.LoginEngineName := 'demo_eng' AsaSession1.ServerParams := 'start=dbeng6.exe -n demo_eng "C:\Asa6\asademo.db" -n demo_db'
|"I am trying to connect to an SQL Anywhere 5 network database server loading two different database files. On the client-side I'm running DBCLIENT.EXE as an NT service. The service is configured to NOT interact with the desktop. If I try to connect to any of these databases I get an error '-83: specified database not found'?"|
When connecting to your database using the SQL Anywhere Client
(DBCLIENT.EXE), running as an NT service without desktop interaction,
SA will fail to connect if the ENG= parameter is specified in the
connection string. To avoid this behavior both
TAsaSession.LoginEngineName and LoginDatabase properties should be
cleared before you attempt to connect. Instead use the
ClientParams property directly to specify the connection details:
try AsaSession1.ClientParams := 'agent=client;dbf=MyDatabase2'; AsaSession1.LoginDatabase := '' AsaSession1.LoginEngineName := '' AsaSession1.ServerType := stClient; AsaSession1.Connected := True; except on E: EAsaException do ShowMessage(E.Message); end;
|"Could you suggest a listing of 3rd-party components which provide drivers for NativeDB?"|
NativeDB will work with most 3rd party products through the Borland
VCL/CLX TDataSource component. However, some 3rd party companies have
special drivers for NativeDB: Flexible reporting tools are
available from ReportBuilder Pro DADE,
the Shazam Power Query components
library. Other popular 3rd party components include
ASTA for ultra-thin client data-access
over the Internet, ObjectSight for
building object-oriented database applications using persistent business
objects and the Rubicon text search engine."
|"I'm using NativeDB for Kylix 2 on Linux Mandrake 8 (Kernel 2.4.3-20), but are experiencing some strange problems when executing my application from within the Kylix IDE. Everything works fine when executing the application stand-alone, but from Kylix I get the Linux signals SIGALRM(14), SIGIO(28) and SIGIO(29) when I attempt to connect to the database using the TAsaSession.Connected property?"|
NativeDB is internally prepared to handle these kernel signals
gracefully. The issue here is that the signals are catched by the
Kylix debugger before NativeDB get any chance to handle them. So the
workaround is to disable the signals (for the debugger only) through
the Kylix menu "Tools | Debugger | Options", to allow NativeDB to
continue the connection attempt within the IDE in debug mode.
1) Select Tools | Debugger Options
2) Select the "Signals" tab
3) Highlight "14", "28" and "29"
4) Change the option "Handled By" to "User Program"
|"Using ASA7, I'm getting an error '-192: Update operation attempted on non-updateable query', if my query includes an updateable JOIN?"|
The ASA7 option ANSI_UPDATE_CONSTRAINTS controls whether updates
are restricted to those permitted by the SQL/92 standard. It controls
the following update types:
1) Updates of cursors containing JOINS
2) Updates of columns that appear in an ORDER BY clause
3) The FROM clauses is not allowed in UPDATE statements.
To allow your JOIN to be updated, set the option permanently to OFF using Sybase Central or temporary using TAsaSession.SetOption.
|"Is it any way to monitor the different SQL statements sent from NativeDB to ASA?"|
You can include the "-zr
|"I know this is not a NativeDB question, but do you know which ASA EBFs that is approved to run on Windows XP?"|
The following link should answer you question:
|"Using ASA 6.03, I get an Access Violation error when opening a query which has user-defined datatypes in it (e.g 'money')?"|
This AV is caused by a known ASA 188.8.131.5247 bug. The combination ASA 184.108.40.20647 and
a query which includes user-defined datatypes, causes "DBLIB6.DLL" to fail, with an
Access Violation, when opening the query.Sybase has announced a fix to this problem
by build #2946 - Engineering Case #211083. For further details, refer to your ASA
"rdme_ebf.txt" file shipped with the EBF. A workaround is to replace the user-defined
datatypes with the base datatype behind it (e.g. a "money" column could be changed into
"numeric(16,4)"). The permanent solution is to
upgrade your ASA client-interface SW
to a more recent build (EBF).
|"Using ASA7, I'm getting an error '-192: Update operation attempted on non-updateable query', if my query includes an ORDER BY clause?"|
This behavior is controlled by the ASA7 option ANSI_UPDATE_CONSTRAINTS. When initializing
a new database for ASA7 this option defaults to CURSORS, while an upgraded database has
this option turned OFF by default. If you want to disable this constraint to allow the
update, set the option permanently to OFF using Sybase Central or temporary using
TAsaSession.SetOption. If you you don't want to change this database option, the cursortype
actUnique will come to the rescue and will, in most cases, return an updateable cursor.
However, the actUnique cursortype is slightly slower than the actDefault or actFixedScroll
|"I am trying to use NativeDB with the Delphi6 TRIAL Edition, but get an error message '[Fatal Error] File not found: NdbBase.pas', when I compile my application?"|
Unless you are using our Professional edition (w/source-codes), you can't use NativeDB
with the Delphi6 Trial Edition. The reason is that Borland have used a different build
for their Trial edition, thus causing the compiler to complain about the current NativeDB
.DCU format, and in turn attempts to rebuild the units (The error-message you get is caused
by this re-compile attempt). In other words, the .DCU format produced by the regular
Delphi6 Personal, Professional and Enterprise compilers are incompatible with the Delphi 6
|"I'm using TAsaDataset with persistent data-fields. This works very well, but once I add lookup-fields (FieldKind = fkLookup) to the dataset, navigational operations on the dataset starts to work slower. Is it anything I can do about it?"|
On each lookup-field, simply set TField.LookupCache := True. Without caching lookup-fields,
NDB's live server-cursor could potentially re-fetch data from the lookup-table (LookupDataSet)
unnecessarily often, and this could cause this performance problem. Enabling LookupCache is
especially important with larger lookup-tables, or lookup-fields which resides in detail-
tables of a master-detail relationship. Refer to your Delphi/BCB online-help on
TField.LookupCache for further details.
|"Can I use NativeDB with Kylix Open Edition?"|
Unless you are using our Professional edition (w/source-codes) and installed the FreeCLX
library you can not use the NativeDB binaries with Kylix Open Edition. The Kylix Open
Edition cannot use any binaries produced by the Kylix Trial edition, the Kylix Desktop
Developer edition or the Kylix Server Developer edition. You need at least one of these
three editions to use NativeDB on Kylix/Linux.
|"I'm converting an ODBC based application to NativeDB. All our current customer- installations heavily rely on an existing ODBC DSN. So for simplicity reasons and to ease the conversion, is it possible to allow NativeDB to retrieve the connection information from this ODBC datasource?"|
Yes, the ASA connection parameter "DSN=" will do just this. DBLIB (the DB interface that
NativeDB uses) will only use this parameter to get the connection information from the
ODBC datasource. Once connected, all data-access will be plain DBLIB without ODBC
involved. The following sample shows how to setup NativeDB's TAsaSession to connect to
ASA using an ODBC datasource (DSN):
try AsaSession1.ClientParams := 'dsn=ASA 7.0 Sample'; AsaSession1.ServerType := stClient; AsaSession1.Connected := True; except on E: EAsaException do ShowMessage(E.Message); end;
|"I'm a registered NativeDB developer and wonders if I need to purchase a separate Linux/Kylix license in addition to my existing NativeDB license (on Windows/Delphi)?"|
No. All currently registered developers will receive the new Kylix version as part of
their support-deal and their free-updates subscription. Simply make sure you have a
valid support-deal with us, and that your current subscription haven't expired. If you
need to renew your support-deal, please contact our sales department at
|"I'm using TAsaDataset and is updating a query/result-set (Edit-Post) which contains a Stored Function call in the WHERE clause. But I'm experiencing a rather slow update operation. What can I do to improve it?"|
Change your TAsaDataset.CursorType to actFixedScroll. With the actDefault (DYNAMIC SCROLL)
cursors, the Stored Function must be evaluated everytime a row is fetched from the server.
However, with a actFixedScroll (SCROLL) cursor, the function will only be evaluated the
first time the row is fetched. After that the row is kept in an ASA temp table and is
just returned directly from subsequent fetches. PREFETCH is also probably having an impact
here. Try turning it off and rerun the query/updates. It should be faster than now, but
in general using stored procedures in the WHERE clause is not a good thing to do if you
need good performance.
|"Using TAsaDataset, I'm getting an exception '-668: Cursor is restricted to FETCH NEXT operations' when opening a query that contains one or more proxy-tables?"|
This error reflects the driver capabilities of the remote database you are connecting to.
This error is seen when your remote database supports unidirectional cursors only (forward
only). To prevent this cursor restriction, when opening a proxy-table, set your
TAsaDataset.CursorType to actInsensitive. This cursor type is similar to the ODBC STATIC
cursor type and will allow you to both navigate backwards and forward on proxy-tables.
|"Can I use NativeDB with the Delphi 5 Standard edition?"|
For Delphi 5 you need at least the Professional edition to use our VCL based data access
components TAsaDataset and TAsaStoredProc. The Standard version does not have any data
access components or any data aware controls.However, if you don't need to use any VCL
based data-aware controls in your project, you could use our generic data-access class
TAsaSQL instead. Upon NativeDB installation, follow our general setup instructions,
but skip the part to install the Delphi packages. The step to add the NativeDB Delphi5\
directory to your unit search path, must be followed though. When using our components
in your Delphi 5 Standard project, just add "NdbBase" and "NdbAsa" manually to your
unit's USES clause, and create the neccessary TAsaSession and TAsaSQL instances by code,
instead of using the Delphi control-palette. If you require to have the NativeDB
controls shown up in Delphi control-palette, you must create and install your own package
(.DPK) by adding the files "NdbBase.dcu" and "NdbAsa.dcu" to this package.
|"Does NativeDB supports MIDAS and TClientDataset's?"|
Yes, it's supported on the Delphi5/BCB5 implementation. But do note that our lack of
cached updates, will require you enable the TDataSetProvider.ResolveToDataSet property
(set it to True).
|"The latest versions of NDB suddenly caused the link between my Master-Detail based queries to break?"|
Starting from version 1.87 we added a new property to the TNativeParam class (accessed
through TAsaDataset.Params) to make it more compatible with the BDE (TQuery and TParam
classes). This property is called Bound, and stores the current assignment status (True
or False) of the host variable. When TNativeParam.Bound is True, it indicates that the
parameter has been assigned a value explicitly (either design-time or runtime). While
False means that the host variable is still unassigned. When Bound is True, its said that
the parameter is "bound to" the explictly assigned value, and will not retrieve the
parameter value from the Master table anymore. As a result, the Master-Detail relation
would break, if the parameter assigned to represents any of the linked fields. So to
re-establish the Master-Detail link, either reset your TAsaDataset.Params property, or
assign a False value to the TNativeParam.Bound property. The TNativeParam.Bound and the
standard VCL TParam.Bound property has the same behavior, so for more information, refer
to your Delphi/C++Builder online help on the TParam.Bound property. To reset the Bound
property for all parameters, enter the TAsaDataset.Params property and press the Reset
|"One of my tables have a column with a default value of "timestamp". I am trying to retrieve all the rows within a specified timestamp range, by assigning a TDateTime value to a host variable, but my query always returns an empty result-set?"|
The fractional part of a TDateTime second in Delphi/C++Builder is precise to three
decimal places (milliseconds), while SA/ASA supports 6 digits accuracy (microseconds).
So when the host variable is bound to a TDateTime datatype you will not be able to make
a valid comparison. You will solve this problem if you change the database option
DEFAULT_TIMESTAMP_INCREMENT from the initial value of 1 to 1000.
|"I issued an SQL with the 'Count' function but TAsaDataset returns more than one row. It seems that any query containing aggregate functions return more than one row. Why?"|
This problem is caused by a bug in some ASA6 and ASA7 EBF's. These EBF's doesn't set
the EOF and BOF markers properly when navigating NEXT and then followed by one or more
PRIOR cursor navigations. You need to upgrade to a later ASA build, or as a workaround,
change your cursortype to actFixedScroll or change your database option PREFETCH to OFF.
A permanent fix is now available with ASA EBF 220.127.116.113.
|"Using Borland C++Builder I get an Access Violation (AV) when calling the OpenRead/ OpenWrite methods?"|
This problem is seen if you pass a C NULL pointer in the "VarValues" variant array
parameter to specify that you are not using any host variables. Pass a "&Null" variant
instead, followed by a dimension count of zero (0).
AsaSQL1->OpenRead("select * from customer", &Null, 0);
|"I'm using C++ Builder 4, but get an EAccessViolation (AV) in the NativeDB module NdbBase once I launch my app. executable. This error only shows up when I run my application EXE outside the BCB4 environment?"|
This is a BCB4 linking problem, and is only a seen using the Trial version of NativeDB.
The Trial version includes the BCB4 standard module "SYSINIT" to check the system
variable "ModuleIsPackage" to decide if your application is running in designtime
or runtime mode. Make sure your linker (ilink32) includes the BCB4 system module
SYSINIT.OBJ or the corresponding lib file.
|"When I try to connect my TAsaSession object to the database I get an AV?|
This problem is typically a result of a DLL conflict when you have mulitple SA/ASA
installations on the same PC. In this situation you need to force a path to your ASA
DLLs. Use the TAsaSession.LibraryPath for this purpose and let it point to the correct
ASA directory where the dblib?.dll file resides. This would typically be the \Win32
directory under your ASA installation home directory.
|"When calling TAsaDataset.Edit, I sometimes get a 'Could not perform the edit because another user changed the record' exception. What is the best way to handle this concurrency problem?"|
This error is seen when NDB detects that another user has updated the
record that you currently try to edit. So you have to decide if you want
to let the current user procceed with his updates or not. A nice way could
be to warn the user, that the row has changed, by defining an OnEditError
handler with your TAsaDataset. In this handler you could let the user
decide to continue/retry the edit process or abort the operation.
An OnEditError similar to the following could be used:
procedure TForm1.AsaDataset1EditError(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction); var Confirm: Word; begin Confirm := MessageDlg(E.Message + '. Abort or Retry the operation?', mtConfirmation, [mbAbort, mbRetry], 0); if Confirm = mrRetry then Action := daRetry else Action := daAbort; end;
|"I get an error if I try to install the NDB packages with Delphi 4?"|
A Delphi 4 bug is actually causing this. You need to upgrade your current D4 version
to the latest service pack.
|What is the difference between the OnConnectionDropped and the OnConnectionTerminated events offered by TAsaSession?|
OnConnectionTerminated is a "polling event" fired by the next database access function
that detects the loss of connection. All internal buffers and connection properties are
reset automatically before the event is called. OnConnectionTerminated is supported by
all SA/ASA versions from WSQL3.2 to ASA7.
OnConnectionDropped on the other hand, is utilizing a new feature of ASA 7.01. This event is triggered real-time and reports a connection drop back to the application, as a callback. TAsaSession translates this callback into a Delphi/C++Builder user event. OnConnectionDropped is reporting a drop of connection that is caused by liveness timeout. Internal buffers and connection properties are NOT reset automatically upon calling the event. Its the programmers responsibility to reset or reconnect by assigning a proper value to TAsaSession.Connected. OnConnectionDropped is sensitive to reentrancy and you can not call other NDB dataaccess functions from within it. To avoid reentrancy problems, the following sample illustrates how to put this event into good use.
// User defined windows message declared with global scope. const WM_RECONNECT = WM_USER + 1; . . procedure TForm1.WMReconnect(var Msg: TMessage); begin // Toggle the connection property to force a database reconnection. AsaSession1.Connected := False; AsaSession1.Connected := True; end; procedure TForm1.AsaSession1ConnectionDropped(Sender: TObject); // User defined event handler for the OnConnectionDropped event. begin // Avoid reentrancy by posting (not SendMessage) the user defined // windows message to the application message queue. PostMessage(Handle, WM_RECONNECT, 0, 0); end;
|"Is there a way to avoid my application from 'hanging' if it gets blocked by another transaction holding an exlusive lock on the same row?"|
You have two options to avoid this situation. Either you can turn the database option
BLOCKING OFF, or you can handle the blocking inside your own TAsaSession.OnServerWait
event. This event is called repeatedly while the database operation is blocked. If you
want to timeout the blocking you can call TAsaSession.Stop to cancel the operation.
|"Why am I getting an error if i try to start the ASA network server engine using TAsaSession?"|
The network server engine has a way of protecting clients from starting and stopping
databases. This mechanism is controlled by the "-gd" startline switch. When starting
the network server engine from within your application you need to use "-gd all" as
part of the "start=dbsrv7.exe" parameter. This switch is only required by ASA6 or
|"Does NDB support persistent fields as I am used to with TQuery?"|
Yes. NDB fully support persistent fields, including calculated fields and lookup fields.
After dropping a TAsaDataset instance to a form or data module, double-click it and add
persistent fields as needed.
|"Can I execute batches of SQL statements with NativeDB?"|
Batches or groups of statements are supported by SA/ASA and can be executed through
NativeDB. Batches of statements are typically used with compound statements. In contrast
to stored procedures, compound statements are executed "on the fly" by the client
application, while a stored procedure are stored in the database. A compound statement
starts with the keyword BEGIN and ends with the keyword END. In cases where you don't
want to write stored procedures, groups of statements are very convenient.
The following are examples of using compound statements:
ABatch := 'begin' + ' declare cust_id int;' + ' set cust_id = 101;' + ' select * from customer where id=cust_id;' + 'end'; AsaSQL1.OpenRead(ABatch, Null);Or using an atomic compound statement that doesn't return a cursor:
ABatch := 'begin atomic' + ' declare cust_id int;' + ' declare phone_no char(12);' + ' set cust_id = 101;' + ' set phone_no = ''3175558414'';' + ' update customer set phone=phone_no where id=cust_id;'+ 'end'; AsaSQL1.Execute(ABatch, Null);The above examples use NativeDB's TAsaSQL component. The same statements could also be used with TAsaDataset filling the SQL property and calling TAsaDataset.Open with the batch that returns a cursor, while TAsaDataset.ExecSQL for the atomic statement.
|"Why do I get trailing blanks right padded to all character fields?"|
This problem is caused by the SQL Anywhere database create-option "Ignore trailing
blanks in Comparisons". When creating the database via Sybase Central, you will see a
checkbox option "Ignore trailing blanks...". Turning this feature ON will cause all
string-fields to include trailing blanks. To trim off these trailing blanks, when data
is fetched into your application, set the TAsaSession.TrimBlanks propertyto True.
If you instead want to totally disable this database option, follow these steps:
1. UNLOAD the old database.
2. Create a new database with "Ignore Trailing Blanks..." unchecked.
3. Run the Reload.sql script, as created by UNLOAD, on the new database.
|"Can I connect to a Watcom SQL server, using NativeDB?"|
Yes, you can. The following properties of TAsaSession, shows an example when
connecting to WSQL4, over a LAN:
procedure TForm1.btnConnectClick(Sender: TObject); begin AsaSession1.ClientParams := 'start=dbclient.exe -x tcpip'; AsaSession1.LibraryFile := 'dbl40t.dll'; AsaSession1.LibraryPath := 'C:\Program Files\Sybase\wsql40\nt' AsaSession1.ServerType := stClient; AsaSession1.LoginEngineName := 'MyServer'; AsaSession1.LoginDatabase := 'MyDatatbase'; AsaSession1.LoginUser := 'dba'; AsaSession1.LoginPassword := 'sql'; AsaSession1.Connected := True; end;
|"How can I translate strings in my OEM based database collation through NativeDB?"|
TAsaSession has a property named OEMConvert. If set to True, all database input/output
will be translated back and forth from ANSI to OEM characters. This feature translates
characters using the CharToOem and OemToChar Win32 API functions.
|"Should I use TAsaDataset or TAsaSQL to access my data?"|
You can use either/or, or a mix between them. TAsaDataset is designed to work with Borland
data-aware components (DBGrid, DBEdit etc), while TAsaSQL is designed with optimal ease of
use and flexibility in mind. Actually TAsaDataset is just a wrapper class around a TAsaSQL
instance, with added support for VCL data-aware controls.
|"How can I think about TAsaSession compared to VCL's TDatabase and TSession?"|
|TAsaSession is actually a representation of both, while different in implementation and design. The requirement for one TAsaSession in each thread, makes it related to TSession while the general database connection methods relates it to TDatabase. Also note that TAsaSession contains all the database and connection settings that TDatabase keeps and maintain within the BDE and ODBC configuration tools.|
|Copyright © 1995-2020 Liodden Data - All rights reserved - E-Mail: firstname.lastname@example.org||Last modified:|