Valentina Kernel FAQ

Valentina is not RAM-based. Your database can be much larger than the installed RAM. However, the more memory Valentina has to work with, the faster it will be. Starting from v2 Valentina can use RAM-based Databases and Tables.

You can get information on the Valentina Formats page.

Find it out at the dedicated How to Diagnose Problems with Databases page.

The installer of a Valentina product on Windows creates the folder

\Program Files\Paradigma Software\VComponents_win_vc

it also adds the path to this folder to the environment variable PATH. To see this variable you can:

• open the Properties of “My Computer”
• select the tab panel “Advanced”
• click the button “Environment Variables”
• at the bottom of the new window you can see a list of “System Variables”. In this list you can locate the PATH variable.

We had this issue few times, the affected developers have COPIED the path to VComponents folder into the PATH string, and after this Windows could find the Valentina DLLs.

Valentina database files are the same for 32-bit and 64-bit modes.

Of course executables are different, like for any other application or library. Although MAC OS X allows to pack few branches of code into single file, we tend to provide different archives for 32 and 64 bit executables and ADKs.

Those numbers mean: Init Valentina engine with 5 Megabytes of cache.

• 1 Kb - this is 1024 bytes.
• 1 MB - this is 1024 Kilobytes, i.e. 1Mb = 1024 * 1024 bytes.

YES. User for this mode parameter of VDatabase.Create() function.

In empty database, for each logical file of DB, e.g. field or index, one or even few empty segments is/are allocated, which will be filled later by data.

Do not worry about this, because if you are going to add many records later, your database will not grow some time, later more segments will be allocated automatically when required.

Do not worry about this also because those files contain zeros, you can easily zip even few Mb empty databases into few KB archive if needed.

YES. You can use parameter SegmentSize of VDatabase.Create() function. Make it 1-2-4Kb instead of 32Kb on default.

DropTable is expected to be faster, because when you delete record by record, engine checks constraints and links in order to delete linked records. DropTable() simply deletes the table, and tries to do fast operation to cleanup links if any.

It eats ZERO bytes on the disk, and ZERO bytes in the cache. When you work with it as a field it acts as 4 bytes field of ULONG type.

Yes of course. RecID field in this case won`t harm you at all.

Then you must to use regular way of Relational Model with Primary Keys. Valentina DB offers for this Serial32/Serial64 field types. Also you can use Sequences. Please notice that autoincrement in Valentina DB is based on RecID field, so it will reuse values.

NO, record is never moved during its lifetime with normal db operations. This can happen only with the help of Refactoring commands such as COMPACT or Dump/Load. Note, that refactoring operations always take care about synchronization of all ObjectPtr and BinaryLinks in this case.

No, because this is a fundamental nature of RecID field - it is a physical address of a record.

RecID field is kind of virtual field. Valentina shows virtual fields if you do “SELECT ** FROM T” or if you specify such field by name explicitly.

ObjectPtr field will be created in not complete state. Later you should assign a correct Tagret using VObjectPtr.Target property. You may wish to use this trick to be able create tables having circular reference.

Valentina provides both API and SQL SQL commands to ease the execution of this task. Read details about Link Refactoring.

Talking about fld.SetBlaink() notice that exists more often used tbl.SetBlank() method, which you can use in API-way code to prepare Record Buffer before assign new values for new record. fld.SetBlank() assigns value of field to DEFAULT value if it exists, otherwise to NULL if field is nullable, otherwise to something “empty”: zero for numbers, empty string for strings.

fld.put_IsNull() assignes field value to NULL if field is nullable, otherwise to empty value.

blob.DeleteData() removes all segments of a BLOB value. Effectively such BLOB value is same as NULL value.

Yes you can do this for closed db.

You can execute the SQL command “REINDEX DATABASE” (using VDatabase.SqlExecute() or VDatabase.SqlQuery() methods).

Most probably you have individual collation settings for some fields which are used in the query. So, such a field has its OWN collator and ignores the database's and table's ones.

Because in fact it not use index, but its storage is so effective that it looks indexed. Always.
This is why there is no sense to set flag Indexed OFF.

If a String, VarChar or Text field is indexed by words, then an index of this field is built for each word of the field. So there is no way to use the field to sort (i.e. in an ORDER BY clause).

You can create a calculated field equal to this field, but do not make it indexed by words. Now you can sort by this calculated field.

Because they are too small and there is no any sense todo this.