Error Messages

Look up the message you saw on screen. Unless noted otherwise, the graphical application and beye use the same wording. For anything not listed here, open the Log Viewer (Help > View Logs); the log usually names the segment or the database error behind the message.

The database is incomplete

The database is incomplete: 12 of 287 segments are missing records (TXW_BSEG, TXW_BKPF, …). The log records what went wrong for each of them. Do not use this database; fix the cause and run the command again.

Some segments received fewer records than the extract contains. Everything that could be written was written, so the database looks finished — but it is not, and the missing rows would silently be absent from any evaluation built on it.

beye write-to-file and the GUI's Write to file use the same message for CSV files; there it is the files, not a database, that are missing rows.

Take the wording literally: do not use this database. The numbers in the message name how many segments fell short and the first few by name; the log has an entry for every one of them, with the reason and the counts.

The usual causes are a data type the target database will not accept, a column name it treats as a reserved word, or a disk that filled up during the run. The log entry for a failed segment names the database's own error, which is the fastest way to tell these apart. Fix the cause and run the command again against an empty database.

The CSV files are incomplete

The CSV files are incomplete: 12 of 287 segments are missing records (TXW_BSEG, TXW_BKPF, …). The log records what went wrong for each of them. Do not use these files; fix the cause and run the command again.

The same situation as above, for beye write-to-file and for Write to file in the window. Read that section; everything in it applies, with files in place of tables.

Values could not be read

The database is incomplete: every record was written, but 3 values in 1 of 287 segments could not be read and were left empty (TXW_FI_POS). The log names each value, its field and its segment. Do not use this database; fix the cause and run the command again.

Every record arrived, but some of the values inside them did not. DaRT Reader reads each field into the type the extract itself declares for it — an amount into a decimal column, a date into a date column — and a value it cannot read has nowhere to go in a typed column, so the cell is left empty.

An empty cell looks exactly like a field the extract deliberately left blank, which is why this is reported rather than passed over. Do not use the output: any sum or comparison over the affected column is missing those values without saying so.

There is a second form of this. A value can be readable in itself and still be longer than the extract says the field is — a language key of two characters where the field definitions allow one. Taking it over would mean cutting it short, so the field is left empty and the run reports it the same way:

The value "DE" in field SPRAS of segment TXW_T604B is longer than the 1 character the extract declares for that field. Taking it over would have cut it short, so the field was left empty; beware the data may be corrupted.

The log has one line per value, in the form Could not convert "…" to BigDecimal in field DMBTR of segment TXW_FI_POS. Open the Log Viewer (Help > View Logs) and search for Could not convert.

If you renamed the segment or the field with table-rename, the line names both, the extract's name first and the database's after it:

Could not convert "…" to BigDecimal in field DMBTR (written as AMOUNT) of segment TXW_FI_POS (written as BSEG). The field was left empty; beware the data may be corrupted.

Search for the extract's name, or for written as. The messages of beye validate name a renamed table and a renamed grouping field the same way. The field and the value together usually say what happened: a damaged extract, or a field DaRT wrote in a way this version does not yet read. Send the lines to support; they are enough to work from and contain no other data from the extract.

Two further lines can appear there, both saying that values were written but counted against no segment: … were counted against no segment because the progress does not track it and Wrote … records of … that were counted against no segment. Neither is expected. If one does appear, the summary above cannot speak for that segment — it will be called complete either way — so treat the run as unfinished and send the lines to support.

The CSV export reports the same thing with CSV files in place of database.

The database does not match the extract

The database does not match the extract: 1 of 287 segments received every record, but their contents do not add up to the checksum the extract declares for them (TXW_FI_POS: read 733819412, extract declares 733819156). Either the extract is damaged or it was not read correctly. Do not use this database; fix the cause and run the command again.

Nothing is missing here. Every record of the segment arrived and every value in it could be read — this message is about the content itself.

Alongside each segment, a DaRT extract stores a checksum over everything SAP wrote into that segment. After the write, DaRT Reader adds up the records it read for the segment and compares. When the two figures differ, the records in the database are not the records SAP put in the extract, and no other check in the product can tell: the record count is right, the values convert, the lengths fit. A single amount changed from one valid amount to another looks completely ordinary and shows up only here.

There are three possible causes, and the message cannot tell them apart:

• The extract is damaged. A truncated or partially overwritten download, a fault on the medium it was copied from, or a file edited after SAP wrote it. Take the extract again from the source and compare the two copies.
• DaRT Reader read it wrongly. A DaRT release or a code page this version does not handle correctly. Send the two figures from the message, the segment name and the DaRT release (Help > About names what was detected) to support.
• The extract came from a non-Unicode SAP system, and the message is wrong. See below.

Do not use the database. Unlike missing rows, there is nothing here to spot by inspection — everything looks present and plausible.

The CSV export reports the same thing with The CSV files do not match the extract.

Extracts that carry no checksum for a segment cannot be checked this way, and neither can a demo run, which stops after one record per segment. In both cases the run passes without this comparison being made; the record counts and the value checks still apply.

When this message is wrong

⚠️ On an extract from a non-Unicode SAP system this comparison can report a difference over a database that is perfectly correct — and then it does so for every segment at once, not for one or two.

SAP does not compute this checksum the same way everywhere. It adds up characters, and how wide a character is depends on the system that wrote the extract: two bytes on a Unicode system, one byte on a non-Unicode one. The comparison assumes the Unicode form, which is what extracts from current SAP systems use. An extract written by an older, non-Unicode system carries a figure computed the other way, and the two cannot agree no matter how correctly the extract was read.

The extract does say which kind of system wrote it — Unicode mode in the directory file — but this version does not use it to step aside from the comparison. What points at the case:

• Every segment is listed, not a few. A damaged file or a misread field affects some segments; this affects all of them.
• The extract states Unicode mode No or Selection, which the Inspect extract view shows. Those are the two an older, non-Unicode system writes; Yes rules this case out.
• The two figures differ by a large, consistent factor rather than by a little.

If that is what you are looking at, the database is very probably fine, and the other checks say so: the record counts match, the values converted, and Compare every value — which reads every value back out of the database — reports nothing. Send the message to taxforge support before discarding anything; this is a limitation of this version, not a fault in your extract.

Values do not match

Values do not match for table TXW_FI_POS: 1 column(s) hold different values than the extract does: DMBTR. Compared every value in 287 table(s): 286 matched, 1 did not.

Shown after a database write when Compare every value is switched on — --verify-digest on the command line, a checkbox in the settings dialog. beye save ends with exit code 2 when it appears.

Every value of every row was read back out of the database and compared against the value DaRT Reader put there. The column named holds something else. The record count is not the issue here: where the counts differ the message says so instead, naming both figures.

What this catches, and nothing else in the product does: a value written into the wrong column, a value cut short by the column type, a conversion that failed for one type, a value changed in the database after the write. It reads every cell, so a single wrong value among millions is found as surely as a whole column.

Where to look:

• A column type that is too small. The commonest cause. A text field longer than the column, or an amount with more decimal places than the column keeps. Compare the column in the database with the field length in the extract (beye list <directoryFile> <segment>).
• The database changed after the write. Another process, or a manual correction.
• A driver of your own. If the run uses your own JDBC driver, its type mapping is the first thing to suspect; run the same extract into SQLite or H2 and see whether the message stays.

Do not use the database until the cause is known. Unlike a missing row there is nothing to spot by looking: everything is present and plausible.

Where the message says every column holds the same values as the extract, but not in the same rows, the values all arrived but landed in different records than the extract has them in.

Rows do not match

Rows do not match for table TXW_FI_POS: 1 of 1000 sampled record(s) hold different values than the extract does the record at byte 2094776 of volume 1 - DMBTR: the extract has -21257.60, the database has -21256.60

Shown after a database write when Compare sampled rows is switched on — --verify-rows on the command line, a checkbox in the settings dialog. beye save ends with exit code 2 when it appears.

Records of each segment were compared record by record — about 1 000 of them unless verify-sample-size in the configuration file says otherwise, and all of them where the segment holds fewer. The message names the record by the volume and the byte offset it was read from, so it can be found in the payload file itself, and names the field, the value the extract holds and the value the database holds.

The causes are the ones listed under Values do not match above. The two checks look at the same kinds of defect from different sides: this one can name a row, the other one covers every row.

Where the message says that records are not in the database at all, rows the reader wrote did not reach the table. Check the log for the segment concerned; a chunk that failed to insert is recorded there.

Values not compared

Values not compared for table TXW_FI_HD: no records of this segment were written in this run.

Not a fault. It says that a check was asked for and could not be made for this segment, which is deliberately not the same message as one that compared everything and found nothing. It does not change the exit code.

The reasons:

• No records of this segment were written in this run — the segment was excluded by selected-segments, or the run is a demo run, which stops after one record per segment.
• The table could not be read — the table was renamed or dropped between the write and the check. The message carries what the database said.
• This table was written without the source coordinate — only for the row check. The columns DR_VOL_ID and DR_SRC_OFFSET are what a sampled row is found by, and they are written only when the row check was switched on at the time of writing. They cannot be added afterwards. Write the extract again with the check on, or use Compare every value, which needs neither column.
• The extract does not say how many records this segment holds — only for the row check, which works out what share of a segment to keep from the record count in the extract's directory.

The row check cannot write its columns

The row check writes the columns DR_VOL_ID and DR_SRC_OFFSET, and the extract already has TXW_FI_POS.DR_VOL_ID. Switch the row check off, or rename the field with table-rename.

The row check adds two columns to every table it writes, and a column of this table is already going to be written under one of those names — either a field of the extract that carries it, or a name table-rename gives a field. The run is refused rather than writing a table in which one name means two different things.

Either switch Compare sampled rows off — Compare every value needs no extra column and still compares everything — or rename the field of the extract with table-rename, described under Renaming tables and fields in the CLI guide.

Check sums do not match

Check sums do not match for table TXW_FI_POS Values do not match for Table name TXW_FI_POS: Period: 02, Company Code: 1000, SHKZG: H -219104 ≠ -219103

Shown by beye validate, which ends with exit code 2 when any group reports this.

A DaRT extract carries business totals in TXW_CHKSUM: for some segments, the sum of an amount field and the number of records, grouped by company code, period and one further field. validate computes the same totals over the database and holds them against the extract. A difference means the database is not the extract — for the group the message names.

The two figures are printed in the notation of the extract: the totals are whole numbers without a decimal separator, so -219104 ≠ -219103 is a difference of one cent on a two-decimal currency.

The message says which of the two figures disagrees:

• Values do not match — the records are all there but their amounts do not add up to what the extract declares. A value was changed, or one was read wrongly.
• Counts do not match — the group holds a different number of records than the extract declares.
• Values and counts do not match — both.

This check is about the figures. A record that was read wrongly can still land in a group whose total happens to come out right, so it does not replace the per-segment checksum over the bytes described under The database does not match the extract, which save runs by itself over every segment.

Do not use the database until the difference is explained. The likeliest causes are a write that was interrupted, a database that was written from a different extract than the one being validated against, or rows changed after the write.

Group is missing from the database

Group is missing from the database for Table name TXW_FI_POS: Period: 02, Company Code: 1000, SHKZG: H — the extract expects 14 record(s) totalling -219103, the database holds none.

Shown by beye validate, and the commonest real finding: the database holds no record at all for a group the extract declares.

This is what an interrupted write leaves behind, and what validating against the wrong database looks like. Check that the configuration file names the database the extract was written to, and that the save run it came from reported success — a run that was cancelled or that ended with an exit code other than 0 leaves exactly this.

Check sums not applicable

Check sums not applicable for table TXW_FI_POS: the extract holds no readable value in DMBTR, so the scale of the total is unknown.

Shown by beye validate. This is not a mismatch. The comparison was not made, and the command does not exit 2 because of it.

The totals in the extract are whole numbers written without a decimal separator, so the sum from the database has to be shifted by the decimal places of the amount field before the two can be compared. Nothing in the extract states that number, and the field itself is not written in a way that settles it — so the comparison is left undone rather than made against a guess, which could report a mismatch over a database that is in fact correct. The rest of the run is unaffected: other tables are still compared, and the summary counts this one separately.

Cannot read GROUP_TOT

Cannot read GROUP_TOT for Table name TXW_FI_POS: Period: 02, Company Code: 1000, SHKZG: H — the extract holds “21x103-”, which is not a whole number.

Shown by beye validate. The expectation in the extract — not the database — cannot be read as a number, so this group cannot be compared with anything.

It points at the extract rather than at the database: a damaged download, or a file changed after SAP wrote it. Take the extract again from the source. The same message appears with GROUP_CNT when it is the record count that cannot be read.

Cannot ask for a password

Cannot ask for a password: this run has no terminal. Put the password into the "database-connection" section of the configuration file instead, which is how an unattended run supplies one.

Shown by beye save -p and beye validate -p when the command has no terminal to ask on — running under a pipe, from a scheduler, or in a CI pipeline.

-p exists to keep the password off the command line, where it would end up in the shell history and in the process list. That only works where there is a terminal to type it into. For an unattended run, put it in the configuration file instead:

"database-connection": {
  "type": "bundled-driver",
  "driver": "postgresql",
  "connection-string": "jdbc:postgresql://host:5432/dart",
  "user-name": "dart",
  "password": "…"
}

and keep the file readable only by the account that runs the command.

The payload file is incomplete

The payload file is incomplete: it does not end with the record DaRT writes to close a payload file. That is what a copy that did not run to its end looks like. Take the extract again from the medium it came from.

Shown by beye inspect and by the extract overview in the window, underneath the figures for the file it concerns.

DaRT appends a closing record to a payload file once it has finished writing it, and notes the size of the finished file in it. A file without that record was never finished — whatever its size suggests, and whether or not the size happens to look plausible. In practice this is a copy that broke off: a download that was interrupted, a stick pulled out early, a network share that dropped.

There is nothing to repair in the file. Take the extract again from the medium it came from, and copy every file of it — a split extract consists of the directory file and all its volumes, and any one of them may be the one that did not arrive.

The payload file was changed after DaRT wrote it

The payload file was changed after DaRT wrote it: it closes with a record stating 2094830 bytes, but the file measures 2094803 bytes.

The closing record is there, and it states a size the file does not have. Unlike the message above, the file did arrive in one piece; what it holds is not what DaRT put there.

The usual causes are a file opened and saved by some other program — a text editor, a virus scanner that repaired something, an archiver that converted the line endings — or a fault on the medium the extract was copied from. Nothing about the extract can be trusted after this: take it again from the source and compare the two copies.

The directory file does not belong to this payload file

The directory file does not belong to this payload file: it states 2094244 bytes for this volume, while the payload file closes with a record stating 2094830 bytes.

Both files are intact in themselves and they disagree about each other. The usual cause is a folder holding the files of two extracts, where the directory file of one run ended up next to the payload files of another — the names are similar enough that this is easy to do. Check that both come from the same run: their names share a stem, the directory file being the stem plus _DR and the payload files the stem and the stem plus _01, _02 and so on; if two runs have been mixed, take the extract again rather than sorting the files by hand.

The directory file and this payload file come from different DaRT extracts

The directory file and this payload file come from different DaRT extracts: the directory file was written by extract 0050569492781EEBA8BE268D31100858, the payload file by extract 0050569492781EEA85F4AE4072CDC82A. Reading them together gives wrong data with no sign of it. Find the directory file that was written with this payload file.

Both files are complete and sound in themselves — nothing is damaged — but they were written by two different runs of DaRT, and reading them together gives wrong data with no sign of it: the offsets the directory file holds land in the wrong place in the payload file. It happens because two runs of the same extract produce the same file names, so a restore from the wrong medium or a copy that replaced some of the files but not all of them is enough to mix them. Take the extract again from the source, or find the directory file written in the same run as this payload file — the one whose identifier matches the message; do not pair them by hand from the file names.

The payload file is missing

The payload file is missing. It has to lie in the same directory as the directory file.

The directory file names a payload file that is not next to it. An extract is read through its directory file, so all of its files have to sit in one folder together. Copy the missing one over from the source, or copy the whole extract again.

You do not have a valid license key

You do not have a valid license key.

The licensing service rejected the key. Check the key under File > Settings; the command line reads the same setting, so correcting it once is enough for both.

This answer is final — the program does not retry it, because repeating the request would only delay the same verdict.

The licensing service is temporarily unavailable

The licensing service is temporarily unavailable. Please try again in a moment.

The key was not rejected; the service did not answer properly. The program already tried three times before showing this, so an immediate second attempt is unlikely to help — wait a moment and start the command again.

If it persists, it is worth checking whether the machine reaches the internet at all, since the program has to ask the licensing service before it reads an extract.

An unexpected error occurred

An unexpected error occurred.

The licensing service answered in a way the program does not recognise — neither a rejection nor a server fault. The Log Viewer records what came back; that entry is what support needs.

The payload file does not state an encoding this version can read

The payload file /data/DART.TXT does not state an encoding this version can read. An extract written with an explicit code page rather than the system's own is one known cause. Contact taxforge support with the extract's directory file; this is not something that can be corrected here.

Nothing is read from the extract, and nothing is written. The file is not damaged — the reader simply cannot tell which characters the bytes stand for.

DaRT records how it encoded a payload file, and offers four ways of doing it: the system's non-Unicode encoding, the system default, UTF-8, and — from release 2.6 — an explicit code page chosen when the extract was produced. This version reads the first three. The fourth is the known cause of this message.

Send the directory file to support. It is small, it carries no records from the extract, and it states which of the four was used. If the extract can be produced again, one written in UTF-8 is read without any of this.

This does not look like a DaRT directory file

'/data/extracts/Z_Test2' does not look like a DaRT directory file: its first record carries no DaRT release. The directory file of an extract usually ends in '_DR'; the payload files lie next to it and are read through it, not opened directly.

An extract is a directory file plus the payload files it points at. Only the directory file is opened: it names the payload files, and everything is read through it. Picking a payload file directly is the common cause of this message — in a folder whose files all look alike, the one ending in _DR is the one to select.

The other cause is a file that is not part of an extract at all. Whatever it is, only its first record is examined, so it is turned away at once rather than after being read to its end.

The DaRT release is one this version does not read

'/data/extracts/Z_Test2_DR' is a DaRT directory file of release 3.1, which this version of DaRT Reader does not read.

The file was recognised as a directory file, so this is not the wrong file — it was written by a DaRT release this version does not cover. Releases 2.0 through 2.8 are read.

There is nothing to repair in the file; reading it needs a version of DaRT Reader that knows the release. The release named in the message is what support needs in order to say whether one exists.

No data in extract

No data in extract. Check whether you selected any segments.

Shown by the graphical application only. Nothing was written, because nothing was selected — tick the segments you want before starting the write.

A segment is not part of the extract

Segment TXW_CUSTX is not part of extract. Nothing was written.

Segments TXW_CUSTX, TXW_COMPD are not part of extract. Nothing was written.

Shown by beye write-to-file when one of the segment names given on the command line is not in the extract. The usual cause is a typo or a name from a different extract; beye list <directory-file> prints the names this extract holds.

The run stops before any file is created, so the output directory is left as it was.

The command line is refused

Directory file does not exist: /data/extracts/Z_Test2_DR

Config file does not exist: /etc/dart/save.conf

Write directory does not exist: /data/out

Write directory is not a directory: /data/out/TXW_CUST.csv

sep-size cannot be negative.

The command was not started, because an argument cannot be what it has to be. Each message is followed by the usage of the command, and the exit code is 1 — the same code as for a run that could not be made for any other reason.

These are checked before the extract is opened and before the licence is confirmed, so a mistyped path costs nothing but the message. A configuration file that could not be found used to end the run with the path alone on screen and no word about what was wrong with it.

The write was cancelled

The write was cancelled. The database holds only the segments written before it stopped. Do not use this database; run the write again.

The write was cancelled. The CSV files hold only the segments written before it stopped. Do not use these files; run the write again.

Shown by the graphical application after Cancel is pressed during a write. It is not a fault: the run stopped because you stopped it.

What is on disk is a part of the extract that looks like the whole of it — the segments written before the run stopped are complete, and the rest are absent or empty. Nothing marks the difference from inside, which is why the message says not to use it. Drop the database or the directory of files and start again.

The write stops at the next boundary between groups of segments rather than instantly, so a few more records may be written after Cancel is pressed.

The CSV separators cannot be used together

The field separator and the decimal separator are both ','. Amounts are not written in quotes, so every one of them would split its row in two. Use ';' with ',' or ',' with '.'.

A double quote cannot be the field separator: it is what encloses a text field.

A line break cannot be the field separator: it is what ends a record.

The field separator has to be a single character, not ";;".

The two characters a CSV file is written with — set in the settings dialog under CSV field separator and CSV decimal separator, or with -f and -d on beye write-to-file — cannot be carried out as given. Nothing is written; correct the pair and run the export again.

The two combinations that work are ; with , and , with .. Which of them your spreadsheet expects depends on its language: a German Excel reads the first, an English one the second. Leaving both unset uses the pair your machine's region writes.

The reason the first message exists at all: amounts are not written in quotes, so with a comma on both sides every amount would be read as two columns and every row would be one field longer than its header.

The driver could not establish a secure connection to SQL Server

"encrypt" property is set to "true" and "trustServerCertificate" property is set to "false" but the driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption: Error: (certificate_unknown) PKIX path building failed …

This is the SQL Server driver, not the extract. Since version 10.2 it encrypts by default and insists on a certificate it can verify, so a server presenting a self-signed certificate — which is what a fresh installation does — is refused before anything is read or written.

Nothing about the certificate is visible in the message, which is why it is worth knowing. Two ways out, both by adding to the connection string in the configuration file of save:

• ;encrypt=true;trustServerCertificate=true keeps the connection encrypted and stops checking who issued the certificate. Right for a server on your own network.
• ;encrypt=false turns the encryption off. Only for a server you reach over a network you already trust; the data of a tax audit then crosses it unencrypted.

The lasting answer is a certificate the machine trusts, installed on the server. Then neither setting is needed.

A column cannot be declared

Cannot create the table TXW_ACCCAT, because 1 of its 3 columns cannot be declared — KNTTX: a NVARCHAR column needs a field length, and TXW_META gives none.

Cannot create the table TXW_ACCCAT, because 1 of its 3 columns cannot be declared — KNTTX: a NVARCHAR column needs a field length of at least one, and TXW_META gives 0.

Most column types are declared with a field length — NVARCHAR(30), VARCHAR(30), CHAR(3) — and cannot be declared without one. The extract states no length for the field the message names, so that column cannot be created and the table would be one column short.

The table is not created and the segment is reported as not written, which makes the run end as incomplete rather than as a success over a table missing a column. Every other segment is still written; the message names the segment and the field so that the extract can be looked at.

This points at the extract rather than at the database. Ask for the extract to be produced again; if it arrives the same way, the segment named here cannot be written to a database. Writing to CSV files is unaffected — a CSV file declares no column types, so it does not need the length at all.

A table-rename cannot be carried out

table-rename gives the name BSEG to both TXW_FI_OP and TXW_FI_POS. Each table needs a name of its own.

table-rename gives TXW_FI_POS the name BSEG and the name BKPF. Give it one name.

table-rename gives the name AMOUNT to both the field DMBTR and the field WRBTR of TXW_FI_POS. Each field needs a name of its own.

table-rename gives TXW_FI_POS a name that is blank. A name needs at least one character that is not a blank.

table-rename has an entry for TXW_CHKSUM. The segments DaRT writes about itself keep their names and their fields, because the reader reads them back. Use table-prefix to write the extract into a schema of its own.

The table-rename section of the configuration file asks for something that cannot be carried out. The run stops before anything is written, and the message names the line that has to change rather than leaving it to the database to complain about a table that already exists.

Message	What to change
Two segments given one name	Give each its own name. A segment renamed to a name another segment already carries collides just as two renamed segments do.
One segment given two names	Keep one.
Two fields given one name	Give each its own name. A field renamed to a name another field already carries collides just as two renamed fields do.
A name that is blank	Give a name with at least one character that is not a blank.
An entry for a segment DaRT writes about itself	Remove it. See below.

A swap — "A": {"B": …} together with "B": {"A": …} — is not a collision and is carried out as asked.

If the section is wrong in more than one way, every fault is reported at once rather than one per run.

The segments DaRT writes about itself

The directory, the metadata, the selections and the check sums are not your data: they are the extract's own bookkeeping, and DaRT Reader reads them back. beye validate compares the sums in the database against TXW_CHKSUM. Those segments therefore keep the names and the field names the extract gives them.

If the extract has to be kept apart from data that is already in the database, use table-prefix instead. It puts every table behind the same prefix — a schema with a trailing dot, part of the table name without one — applies to all of them alike, and leaves beye validate working.

A settings value is refused

Segments Read at Once must be greater than 0.

Shown as a tooltip next to the field in File > Settings when Save is pressed. The dialog refuses to save rather than storing a value that would do nothing. The fields validate as follows:

Field	Rule
Number of connections	greater than 0
Chunk size per connection	greater than 0
Segments read at once	greater than 0
Connection timeout	at least 250 ms
Max lifetime	at least 30000 ms
Validation timeout	at least 250 ms