Subject Re: [firebird-support] Issues with .Net Data Provider
Author Ivan Prenosil
> >> INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 12345);
> >>
> >
> > 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.

As was already said, something must be wrong with your data provider,
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;

PKEY BIGINTVALUE
=========== ====================
32 12345
32 549755813887
32 123456789012345678





> Yes, I understand all of this. My point was that the size of the
> 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.

Each row needs to store some additional informations, like
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.

Ivan
http://www.volny.cz/iprenosil/interbase/