Hello everyone,
i found out, that the following select statement produces different schemata in
DataTable when using SQLiteDataAdapter.Fill and data rows are returned or not
returned from the SELECT statement.
SELECT 1 AS literal FROM anTable WHERE 1<1
Especially i need those literals in UNION
ars - why not writing a minimal
wrapper and extending step by step. I do it with my C++ wrappers
routinely. It was most of the time the better solution in most aspects
(time, simplicity).
Micha
--
n appends are not easily achieved in hdf5.
Even so, not every read operation. It's still great, when having
multidimensional data in a sense, scientific communities use them.
You can select so called hyperslabs from these fields very, very
quickly.
Micha
--
t; represents and how it will be used?
> Me too!
Me too too :)
_Personally_ I think, this sounds like a task not quite fitting in
sqlites (probably any 'standard' databases) realm. This is a bit
off-topic in this group, but because you mention sub-boxes - did you
ever look into more specialized file-formats like HDF5:
http://hdf.ncsa.uiuc.edu/HDF5/
with support for certain (of course limited) queries ?
Micha
--
CREATE's
documentation, concentrating on ATTACH exclusively.
Beside this, I find it still a bit counter-intuitive too ...
Micha
--
ortened table names, as it
has been stated in the documentation). So, the database should be
properly attached.
This is sqlite 3.3.5
Has anyone an idea, what went wrong here ?
Micha
--
> It is not a smart technique to assume that you can access underlying
> data structures and expect them to remain identically placed between
> releases.
What do you think, was my reason to ask, whether these structures are public
and stable or not ... ;-)
Micha
--
helps to link the file name of one of the databases as a
special table entry into the other. To do so, it would be nice to have
access to the file name at random times.
Micha
--
otherwise than as opaque pointer for the sqlite
interface ?
Micha
--
ot;commit");
return false;
}
}
db_.sql("commit");
The table rows themselves have the following scheme
[primary_key, INEGER, INTEGER, INTEGER, INTEGER, REAL, REAL, REAL]
Is there a quicker way to get rid of a bunch of tables or I'm wrong
in something unseen (by me) ?
Micha
--
man too. IMO, the most
hassle-free way doing these things lies in avoiding encoding issues, if
you can do so. A database is often a 'hidden layer', a good interface
should be able to transform potentially visible parts into something
more perfect (like 'Straße' for an UI).
Micha
--
em behind.
Micha
--
@list
Following the documentation, the two functions have been declared
'experimental'. Does someone know, how reliable these calls are actually
? There are specific serious open issues, rough estimates when to fix
them, etc. ?
Micha
cl stuff sources (forget the actual file name)
from the distribution. The compiler spits lot of warnings (it's not the
important stuff - 'conflict between signed, unsigned type' sort - but
maybe someone could fix this ?), but will eventually create all object
files finely
Micha
--
al
Studio 2003 with his native STL and a recent Redhat Linux on Opterons.
Micha
--
item,
dealing with performance. Would it be possible to give some emphasis to
the problem in the standard documentation too ?
Thank you for the software, Richard (et al ?).
I like the library a lot.
Micha
--
performance ?
2)
Database design. Is this big table a good choice or has anyone
recommendations for better design. For example, splitting the big table
into smaller ones (assigned to a single entity) with ~10 rows and
later on building database requests utilizing joints ? Or something
completely different ?
Thank you,
Micha
--
17 matches
Mail list logo
