NexusDB

Most likely you hit an OS problem. For a complete list of public error messages

in windows take a look at this MSDN page.

Our bookmark implementation saves the index info in the bookmark, so the answer would be 'no'. Use a different index from the one you are changing data in.

The RefNr is already in there. (for non-unique indices the RefNr itself becomes part of the key as the B*Tree algo itself only operates on unique keys)

The problem is that RefNr's are reused. There is no way to distiguish between a record that had has been deleted and the RefNr reused for a completely different record and a record that has been modified which resulted in changed keys. A bookmark is supposed to bring you back to the record it came from. Using RefNr alone is not guaranteed to do that. In the end it comes down to the definition of "record identity" and that is currently defined as key + refnr.

Set the client side transport's HeartbeatInterval to 0 before activating the transport. Remember to set back the original value when you are finished debugging.

Yes there is a possibility.

First, the firewall comes into play only if one wants to access the Nexus server from outside the server's subnet. So it takes this as a fact.

Second, it has nothng to do with Ping being blocked by the firewall. One has to configure his/her firewall to allow connections through it on port 16000. This is the TCP/IP port the Nexus server uses by default. In this case clients outside the server's subnet can connect to the Nexus server if they know the server's address. This is usually this external IP address of the firewall. The firewall must be configured to route IP traffic on port 16000 to the machine the Nexus Server is running on. Still no broadcast but connections can be made to the server.

Third: If one want the clients to find the server behind the firewall automatically, he/she needs to make sure broadcasts make it through the firewall and the Nexus server must be configured to respond to broadcasts. So one has to configure the firewall to pass the Nexus client's broadcasts to the server. Broadcasts are using UDP protocol but it doesn't know the port.

If you want to use your product with Nexus MM/DB and MadExcept, please use the following order for the unit intialization in MadExcept:

nxllFastCpuDetect, nxllFastFillChar, nxllFastMove, nxllMemoryManagerImpl,
nxllMemoryManager, nxReplacementMemoryManager

If you look a the NexusDB sources, the only place where this is error is triggered if different threads are accessing the sames session concurrenly. This is not allowed, so in your scenarion there must be at least two threads involved. Make sure that *every* thread is using it's own vcl components down to transport level. The transport level is the first 100% threadsafe one as all others are derived from the non-threadsafe VCL classes.

Unfortunately in almost all cases that will be hard to debug, especially if you're working with a remote server. If it's a local serverengine then open nxsdServerEngine and put breakpoints on all lines that fire the DBIERR_REENTERED error. Once you stop at one of these lines, take a look at the threadview and the stacktrace of each to figure out what the thread is and where it's coming from ...

It looks  like nxExceptionHook logs errors when they're raised while Eurekalog logs errors when they aren't handled by the application. Nexus seems to find a way to handle and ignore most errors after they're logged by nxExceptionHook, so none fall through to Eurekalog. Is there any point in adding EurekaLog to Nexus?  Is there an easy way to go about  it?

nxExceptionHook uses the free JCL library to do its work, and yes, it does trap and log exception stack traces just fine. To switch to EurekaLog, undef the {$IFDEF NX_EXCEPTION_LOG}define in the nxDefine.inc file, and add EurekaLog as described in their docs.

Just put a {$D-} as first line into nxDefine.inc and all debugging inside all NexusDB units should be gone.

The server-side watchdog thread will monitor the keepalive messages from the client. If 3 messages go missing, the server declares the client dead, and closes the connection. On the client-side, if the network breaks the connection for any reason, then a "lost communication" exception is immediately raised when a message is sent to the server.

Note that last part. It means that you will not get any event that tells you the connection disappeared, you need to catch the exception that will be raised by your regular database method calls (use Application's global event for instance), and handle it. There is no automatic reconnection, and since its likely that the server has closed all resources your app were using, you should treat a lost connection exception similar to a fresh start of your application.

This is a limitation in Borlands VCL.There is not field type for unsigned 32 bit integers.NexusDB has to map nxtWord32 fields to TIntegerField

Which is a signed 32 bit Integer.

You can work with Word32 fields as long as you remember to do the required typecasting when accessing the field.

e.g.

var x: LongWord;
x := LongWord(Field.AsInteger);
Field.AsInteger := Integer(x);

Internally, YES. Sure. SQL, Filters, Indices... everything handles Word32 correctly as Word32. Only the access to the field in the TDataSet layer on the client side doesn't support Word32, which is a Borland limitation in the TDataSet design. Once you have taken that slight bump by correctly typecasting when accessing the field all is fine.