Starting from v.5.0, you may get count of affected links (pair of records affected by LINK/UNLINK… statement) via QueryResult::get_AsULong()
Each Valentina’s volume consists of set of segments, even internal service-data placed in such segments.
Database storage is implemented similar to some file system. There are volumes (.vdb, .dat, .blb, .ind, .tmp) and there are some embedded files on that volumes (all the data like field-data, indexes and so on go to that files). Each volume operates with own segment map – so we can find (and allocate new) segments for particular embedded file easy and fast.
There are many find-like methods which are able to employ indexes to speed up the searching (FindLike, FindRegEx, FindContains, and so on). Of course, the field must be indexed and search preference is set to kPreferIndexed.
But currently there are two issues when index search may bring a wrong result:
1.Index keeps only first 256 symbols of the value – so rest of the symbols are just ignored in such a search.
2. Index-By-Words index and multi-word searching pattern.
Some of the methods like FindRegEx don’t use an index-search but scan the table instead if any of the above occurred. The rest of the methods are less strict choosing the searching algorithm. Now you will get the warning in such cases and you can switch algorithm to not-index search (kPreferNotIndexed) if it is relevant (less speedy but more accurate). Also you should consider to change index type of such a lengthly fields to the index-by-words.
“Index search in the first 256 symbols only : FindContains t1:f1”
“Index-By-Words search : FindContains t1:f1”
Starting from 4.8 build you may pass pictures as a binded value to the queries using V4NET ADK.
Assume there is some “not-latin” text (it could be russian or umlauts or something similar). And we have to store it to the Valentina database and then read it back.
There is a new property – LogFilesLocation for both server and local.
It defines a folder where the logs should be placed in.
Default folder is “./vlogs”
Now you should not synch vClient API calls – vClient do it self and you are free to access and operates with vClient’s remote objects from different threads similiangly.
In particular, vStudio operates with remote connections via multiple threads and it was a source of some glitches and unexpected errors especially with a long queries. Now there are no more errors like “EOF reached…” or “Broken packet received…” which were result of incorrect thread synch.
ObjectPtr field contains RecID values of some “target” table. If you need to change ObjectPtr in order to point another table those values are not valid anymore – so default behavior is to nullify them. But sometime it looks to be too strong. For instance – changing field or link name or on-delete policy should not cause such data zeroing.
There are two ways to keep existed values altering ObjectPtr:
- There is a global property – OnChangeTypeZeroPtr. It is set to true by default. But you may change it with following statement – “SET PROPERTY OnChangeTypeZeroPtr TO false”. After this altering ObjectPtr will prevent zeroing data (sure it will be nulls for records which are absent in the new target table). This property is not “schema-storable” – so you should set it up on each run if you need it.
- The first approach is a global setting – so you will be able to keep some ObjectPtr values even changing “target” table. So we implement one more way – much more simple because the only thing you should keep in your mind is – the values will be preserved until you touch “target table” ObjectPtr property (because all values will be valid for the same target anyway).
Valentina is a perfect choice to work with a big data. It employs vertical storage approach. It means – each column has own virtual file to be stored in. Most of db vendors use a horizontal storage – it stores a table data in record-by-record manner.
There are some vertical storage advantages:
There is a new feature in Valentina Server – SNMP agent.
Currently we support only get() and get_next() SNMP requests for the following oids:
Not much info but it makes a possibility to monitor vServer over SNMP.
For now, SNMP facilities are available only for Windows.
You should specify SNMP port in the server ini-file (default port is 161, 0 means turn off SNMP agent):
Port_SNMP=161; SNMP port to listen by VServer.
; 0 – do not use a SNMP port.
You may set LogToSysLog variable to 1 (in the INI file or via vServer properties) to make vServer put log messages into the system log:
* Event log for Windows
* SysLog for Linux.
The default state of variable is off.
In some cases we can avoid copying sub-query result to the temporary table. We can even use sub-query cursor “as is” – so it could be used as a result of the whole query. In other words there is almost zero overhead against a simple query.
For now such optimization can be applied if a query:
- contains only “*” item in the select list clause
- has no “where” clause
- has no “group by” clause
- has no “having” clause
- has no “distinct” clause
- is not a part of some join operation
- has no “order by” clause
- has no binding values
- sub-query is not a “union/except/intersect” result
SELECT * FROM (SELECT * FROM t1 WHERE f1 > 5);
SELECT * FROM (SELECT t1.f1, t2 f1 FROM t1 JOIN t2 ON l1 WHERE t1.f1 > 5 AND t2.f1 <3);
It was a huge improvement to solve the problem with a “second run” in stored procedures and binded queries. Sometimes there was an incorrect behavior because of “over-prepared” nodes. There was a workaround with “EXECUTE” statement (which is actually developed to prepare any SQL statement and execute one from another SQL statement). So now this workaround could be omitted.