Frequently Asked Questions

The preferable way to submit a bug is to use the bug tracker system.

Remember, a good rule to follow is to always do a background search before submitting a problem report. Maybe your problem has already been reported; maybe it is being discussed on the mailing lists, or recently was; it may even already be fixed in a newer version than what you are running. You should therefore check this FAQ list, mailing list, existent bugs before submitting your problem report.

In early versions of Sedna you had to drop a database by manually removing database files. Now it is better to use se_ddb command. For details see documentation provided with the distribution or just run se_ddb -help.

It's still possible to remove database manually. Just remove:

data/{DATABASE-NAME}_file folder and
cfg/{DATABASE-NAME}_cfg.xml file

Note, however, we don't guarantee that this method will work in future releases.

Typically this error message means that you have upgraded Sedna to a newer version and you are trying to run Sedna on a database created with the previous version of Sedna. The solution to the problem is so called migration procedure performed by se_exp utility. See Sedna Administration Guide ('Migration between Releases' section) for details.

If you have a number of documents that have similar structure (the structure must not be exactly the same) and you want to query through the documents, you should store them in a collection. Collections are optimized for querying through documents.

How to create and use collection see "Managing Collections" section of the "Sedna Programmer's Guide".

Follow instructions in "Build C-driver (libsedna)" section of the Sedna Installation Guide to build Sedna driver.

Since version 3.5 the default configuration of Sedna does not allow incoming connections from external machines. This implies that no external application can access your databases.

To make it available the two steps have to be done:

1. You have to make Sedna listening for remote incoming TCP connections because the default settings allow to listen only for connections on the loopback (localhost) interface. To be able to reach the server remotely you have to change listen_address value in $SEDNA_HOME/etc/sednaconf.xml. Either set it to the IP address of the external interface you want to connect from, or 0.0.0.0 to allow all external connections (like it was in Sedna prior version 3.5)
2. When you have applied these modifications to your configuration file you need to restart Sedna server (run se_stop and then se_gov again).

Alternatively, you can use Sedna server (se_gov) -listen-address command line option to override default settings or configuration file value.

Now it is possible to login to your server remotely, using the username and password.

The following terminal script creates a new document and inserts root element. Then it inserts a new attribute into it:

CREATE DOCUMENT "a"&
UPDATE INSERT <root><a/></root> INTO fn:doc("a")&
UPDATE INSERT attribute {"name"} {"value"} INTO fn:doc("a")/root/a

Replace attribute with a new one. The following statement updates value of the attribute created in the previous question:

UPDATE REPLACE $x in doc('a')/root/a/@name WITH attribute {"name"} {"new value"}

No, it's not. More likely you have NOD32 Antivirus installed. It conflicts with Sedna and some other programs. The bug is in NOD32, actually. You can solve the problem by configuring NOD32 in the following way.

Sometimes the following NOD32 configuring helps: go to "IMON module->SETUP->Advanced"; here you can exclude se_gov process.

If this does not help turn off NOD32 Internet Monitoring module IMON and then restart Windows: "NOD32 Control Center > IMON > Quit" + System Restart.

It looks like Winsock2 on you Windows XP has been corrupted. Please read this Microsoft support page and try to determine whether the Winsock2 key is corrupted, and if yes - recover from Winsock2 corruption:
http://support.microsoft.com/kb/811259/en

Follow instructions in Sedna Installation Guide to build Sedna from sources.

Most likely, the reason of the problem is lack of memory. By default Sedna requires 100 MB of memory for every running instance of database. You can vary the required memory size by -bufs-num option of se_cdb. For details see "Managing Databases" section in Sedna Administration Guide provided with the distribution or just run se_cdb -help.

If this still does not help then possible reasons/solutions:

1. Sedna servers are blocked by firewall (Windows XP SP2 built-in or third party installed). The solution is to appropriately adjust or turn firewall off.
2. Windows XP SP2 limits half-open connections to a maximum of 10. Some applications, like, for example, filesharing tools, can't unfold their capacity when the maximum connection limit is too low. Look into the event viewer (start->run 'Eventvwr.msc'->system). If you see entries with the event ID 4226 you can try xp-AntiSpy to raise the connection limit.

Sedna doesn't have built-in facilities to work as a Windows service. To workaround this use third party tool named se_svc:

Sources | Binary (128K)

Before using it read carefully readme file available here.

Important Notes:

• To run se_svc successfully you need to be adminstrator or have administrator rights. Open command line (cmd.exe) as administrator (Right click -> Run as administrator).
• By default service is installed to be run under SYSTEM or LOCAL SERVICE special built-in Windows system accounts. Don't forget to check if account service is running under has access to the %SEDNA_HOME%/data and %SEDNA_HOME%/cfg folders including content.
• It's not possible to create/start/stop database and stop/start Sedna using command line utilities even if you run them from the same account as Sedna service works on behalf of. In this case you will have the following error:

      SEDNA Message: ERROR SE4400
      SEDNA server is not running. Did you forget to run se_gov command?
      Details: Can't open GOVERNOR shared memory
  

  To workaround this stop Sedna service (using control panel), run Sedna utilities you need (se_sm, se_cdb, etc), check that Sedna service account has access to every new file in %SEDNA_HOME%/data and %SEDNA_HOME%/cfg folders, restart Sedna service.

Actually, not. Wait for several minutes and try again. The problem is in sockets. The following is what socket FAQ says:

When you issue the close() system call, you are closing your interface to the socket, not the socket itself. It is up to the kernel to close the socket. Sometimes, for really technical reasons, the socket is kept alive for a few minutes after you close it. It is normal, for example for the socket to go into a TIME_WAIT state, on the server side, for a few minutes. People have reported ranges from 20 seconds to 4 minutes to me. The official standard says that it should be 4 minutes. On my Linux system it is about 2 minutes.

A binary version does not have support for SQL Connection for Unix-like operating systems (Linux, FreeBSD, MacOS, Solaris, etc). This is due to the problems of linking Sedna executables with static odbc library. But you can download Sedna sources and compile Sedna yourself with SQL_CONNECTION variable set to ON.

See Sedna Installation Guide or INSTALL file provided with Sedna sources for additional information.

Most likely you just need to adjust your system configuration. Read carefully post-installation setup section of the Sedna Installation Guide.

1. Make sure that you have all libraies you need to run Sedna. Run ldd {SEDNA_HOME}/bin/se_trn (se_cdb process runs se_trn internally) command to check that all dependencies are met. On Mac OS X use otool -L command instead of ldd.
2. On Linux check versions of glibc and glibcxx. You should have glibc 2.4 and glibcxx 3.4.9 or higher.

No, it's not. The standard Sedna command-line console client (se_term) by default is built with ENHANCE_TERM option set to Libedit value. Libedit requires curses to be installed and greatly increases the usability of se_term. It adds all of the standard functionality of the GNU Readline library to the se_term command line, such as being able to easily modify, edit, and retrieve command-history information with the arrow keys.

Depending on your operating system, you have to install either libtermcap, libcurses or libncurses package. In some cases (e.g. Debian, Ubuntu) you have to install libtermcap, libcurses or libncurses development package as well.

For example in Debian/Ubuntu the following commands install libncurses:

• sudo apt-get install libncurses5
• sudo apt-get install libncurses5-dev

This problem can be fixed also by turning off libedit support. See Sedna Installation Guide for the instructions on how to adjust Sedna configuration while building from sources.

One of the possible reason of this behaviour is the /dev/shm temporary filesystem size (use df -h to check it size). Try to extend it using the following command:

mount -o remount,size=<size> /dev/shm (substitute <size> with exact value)

Hopefully, you are. The described situation happens when your Linux installation does not turn on support for shm fs. Without it, it is not POSIX compatible. The problem is known to happen on ALT Linux, some Debian installations (possibly with kernel 2.4). The problem can be fixed by mounting /dev/shm.

1. One way is to issue the following command (valid until system restarts). Note that you need root privileges.

   mount -t tmpfs tmpfs /dev/shm

   If you have no /dev/shm, just create it:

   mkdir /dev/shm

2. Another way is to edit configuration files (also valid after system restart). Note that you need root privileges.

   1. Add the following line to /etc/fstab (if it isn't there already):

      tmpfs /dev/shm tmpfs defaults 0 0

   2. Mount shared memory as follows:

      mount /dev/shm

   3. Issue the following command to check that it mounted properly:

      mount | grep "shm"

      If the mount was successful, then the following output (or similar) should appear:

      tmpfs on /dev/shm type tmpfs (rw)

      If the output from this command is blank, then the mount failed. If /dev/shm fails to mount, then this feature may not be turned on in your Linux kernel. In this case we recommend upgrading to a more recent Linux kernel, or contacting your Linux Distribution vendor for more information on enabling POSIX Shared Memory.

Sedna can be built under x86/x64 architectures only. SPARC architecture is not supported yet.

To build Sedna from sources use the following step-by-step guide, which has been tested on Solaris 10:

1. Download and extract latest Solaris sources package.
2. You will need ar utility. Run:

   find / -name ar

   to locate it.

3. Add "/usr/ccs/bin" (usually contains ar utility) to the PATH environment variable:

   PATH=$PATH:/usr/ccs/bin

   export PATH

4. Make sure that gcc, g++ and make commands are also in PATH.
5. Follow instructions in Sedna Installation Guide to build Sedna from sources.

To run Sedna under FreeBSD you need to perform the following additional post-installation steps:

1. Unfortunately FreeBSD (7.0, 6.3 and earlier) has a bug (PR 123731) in System V semaphores. To run Sedna you have to rebuild your kernel with the patch you can found here.
2. Increase system IPC configuration either using sysctl or through /boot/loader.conf. Below possible values are listed:

         kern.ipc.semmnu=256
         kern.ipc.semmns=512
         kern.ipc.semmni=256
         kern.ipc.semmap=256

   Note: Don't forget to reboot your machine if you changed /boot/loader.conf.