Subject | Issues with .Net Data Provider |
---|---|
Author | Ken & Deb Allen |
Post date | 2005-08-19T00:29:13Z |
I have been experimenting with using Firebird from C#/.Net, and I
have a number of questions/concerns.
First, how does one specify large integer values for insertion into a
BIGINT column via static SQL. The following statement works when the
value of the BIGINT is with the signed 32-bit range, but fails when
the value gets larger:
INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 12345);
Second, I have a potential application that will require an extremely
large number of records in a table, and I have been performing the
initial tests on 10,000,000 records in a table that contains only
BIGINT, INT and TIMESTAMP columns. The 'raw data' size for each
record is 48 bytes, and the only 'index' on the table was the primary
key, but storing 5,000,000 records added more than 801MB to the size
of the database file! The raw size for this many records should only
have been about 200MB, so this is a 4x size factor! I have conducted
a similar test with another database, and the resulting file seemed
to be much smaller (but I need to complete my tests before proceeding
with specific statements).
-ken
have a number of questions/concerns.
First, how does one specify large integer values for insertion into a
BIGINT column via static SQL. The following statement works when the
value of the BIGINT is with the signed 32-bit range, but fails when
the value gets larger:
INSERT INTO MyTable(PKey, BigIntValue) VALUES(32, 12345);
Second, I have a potential application that will require an extremely
large number of records in a table, and I have been performing the
initial tests on 10,000,000 records in a table that contains only
BIGINT, INT and TIMESTAMP columns. The 'raw data' size for each
record is 48 bytes, and the only 'index' on the table was the primary
key, but storing 5,000,000 records added more than 801MB to the size
of the database file! The raw size for this many records should only
have been about 200MB, so this is a 4x size factor! I have conducted
a similar test with another database, and the resulting file seemed
to be much smaller (but I need to complete my tests before proceeding
with specific statements).
-ken