> I will assume _int4() is a typo and you meant _int64() there. Yes sorry. My keyboard needs serious cleaning. ;-) > The answer is No, it has nothing to do with whether you are running a 64-bit or 32-bit application. It has strictly to do with the size of the target variable/memory you want the value of the column to be written to. OK. > If you expect the values to always be smaller than 4-billion, then a 32-bit integer target will do just fine. (These happens to be smaller space-wise, more space-efficient to transfer in say an internet stream, and also used to be faster to do calculations with on older 32-bit systems, hence still prevailing through esp. legacy code.) But then why not have SQLITE_INTEGER64 to indicate that the value is 64 bit integer? > Some applications need values even bigger, like astronomy systems using perhaps > 80-bit integer variables. These applications have to provide their own 80-bit > variable spaces and perhaps their own code for doing calculation with them. The > point here is that the memory/variable sizes holding the data is dependent on > the use case of the data, NOT the bitness of the application, underlying CPU, or > Operating system, etc. Does it still comes as SQLITE_INTEGER in this case? Thank you.