|Subject||Re: [firebird-support] Issues with .Net Data Provider|
> >> INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 12345);As was already said, something must be wrong with your data provider,
> > Firebird won't reject this. Something is happening in the
> > interface. The
> > right place to ask about this is the firebird-net-provider forum.
> > Make
> > sure you explain what "fails" means.
> No, Firebird does not reject the statement above. But when an integer
> literal that is larger than (2^31)-1 (signed integer) is specified,
> then the command is rejected with a syntax or illegal value error (I
> do not have the exact value here). Replace the second value in the
> statement above with 549,755,813,887 (remove the commas) and see what
> happens. I have tried replacing this with 0x7FFFFFFFFF, but that was
> also rejected.
so you should ask on appropriate forum.
Here is copy-pasted result from isql:
CREATE TABLE MyTable(PKey INTEGER, BigIntValue BIGINT);
INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 12345);
INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 549755813887);
INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 123456789012345678);
SELECT * FROM MyTable;
> Yes, I understand all of this. My point was that the size of theEach row needs to store some additional informations, like
> resulting database was much larger than the size of the file created
> by other database packages when the same data was loaded. I used the
> raw data size as a base measurement. Since the only information being
> stored for this table is the raw data and the primary key index, it
> seems odd that the overall storage should be as high as 4 times the
> raw data size when other databases have a lower factor.
transaction-id, format-number, null-flags array, deleted-flag, and many more.
As a result, even if you have table with single Char(1) column,
each row will occupy approximately 30 bytes.
For more comples tables (or tables with larger varchar fiels) the situations
is in fact much better than with other databases (e.g. fixed-record-length dbase),
because all data are compressed before storing to disk,
and sometimes the database can be even smaller that original file
the data were imported from.