Hy everybody,
here's another tiny question.
I'm working on MacOS X 10.4 together with a NSTableView and Sqlite.
If I try to add a formatter to a column containing floats from a
sqlite database (even if I know it's typeless), suddenly when queried
the column doesn't display a single number.
> > Having is applied after the grouping
> > where is applied to filter results before grouping.
> > It will probably make little difference in this example
> > I think you just have a date format problem.
>
> Many thanks. Truly.
> It solved the problem... at least it seems so !! :-))
> BTW, is the
Il giorno 09/dic/05, alle ore 21:29, Jay Sprenkle ha scritto:
On 11/9/05, Sanri Parov <[EMAIL PROTECTED]> wrote:
SELECT date, code, goodie, sum(amount) AS total FROM warehouse GROUP
BY code HAVING (date BETWEEN '10-06-77' AND '12-06-77' AND code
BETWEEN '10' AND '10')
I believe you probably
On 11/9/05, Sanri Parov <[EMAIL PROTECTED]> wrote:
> SELECT date, code, goodie, sum(amount) AS total FROM warehouse GROUP
> BY code HAVING (date BETWEEN '10-06-77' AND '12-06-77' AND code
> BETWEEN '10' AND '10')
>
I believe you probably want:
SELECT date, code, goodie, sum(amount) AS total
FROM
Hi everybody,
I'm quite new to SQL so please be patient on me... :-)
I'm doing a load/unload application for a warehouse and I've got a
table like this
WAREHOUSE:
1 datedate
2 codeinteger primary not null
3 goodie text
4 mu
If you really want a data structure which is independent of processor
architecture and compilers why not byte encode the numbers into what
would be described in Pascal as a Packed Array of Char. Then byte
ordering, word alignment etc are irrelevant.
It does require that the client have a func
On 2005-12-09T10:30:37-0600, Jay Sprenkle wrote:
> This shouldn't work on your compiler:
>
> void* p;
>sizeof(*p)
>
> This should return 1:
>
>unsigned char* p;
>sizeof(*p)
I understand, that is the point of void after all.
The answer to the question was provided previously, na
Hello pps,
I'd argue that serialization's basically the same as marshalling or
using CArchive to serialize in a windows environment. When you
serialize you're enforcing a standard for data packing and alignment
so, you're simply solving the problem in a different way. You're
throwing a layer over
On 12/8/05, Allan Wind <[EMAIL PROTECTED]> wrote:
> On 2005-12-08T10:37:36-0800, Wilson Yeung wrote:
> > You're expected to cast your structure into an unsigned char *,
> > because in C/C++, the only portable way to represent a byte is with a
> > char/unsigned char.
>
> Off-topic, I suppose, but wh
Wilson Yeung wrote:
c++ *guaranties* that char is always one byte. It cannot be anything
else. The difference is that from c++ point of view byte is not limited
to 8 bits (it could be more, but not less). Not sure about c, but I
expect it be the same
The definition of a byte as 8 bits is not l
Teg wrote:
Hello Nathan,
Depends on how you access them. Most RISC CPU's can't do unaligned access
to multi-byte values like int's and long, they'll segfault. Intel
CPU's don't have this problem. If you memcpy the values into place,
this is a non-issue. You see it alot with embedded CPU's.
With
Teg wrote:
Hello Nathan,
Depends on how you access them. Most RISC CPU's can't do unaligned access
to multi-byte values like int's and long, they'll segfault. Intel
CPU's don't have this problem. If you memcpy the values into place,
this is a non-issue. You see it alot with embedded CPU's.
With
Wilson Yeung wrote:
I don't know of a portable representation of a byte other than a char.
And while no one promises that a char is really a byte, I expect that
too much code would break and so it would be many many years before
this is changed in practice.
c++ *guaranties* that char is always
13 matches
Mail list logo
