On 2015/12/03 8:49 PM, Scott Hess wrote:
> On Thu, Dec 3, 2015 at 4:49 AM, R Smith wrote:
>
>> On 2015/12/03 3:04 AM, Scott Hess wrote:
>>
>> I posit that a column declared as: col VARCHAR(32) NOT NULL says a
>> whole lot more about what is actually happening than: col TEXT NOT NULL
> I'm sayi
Good catch, Dirk
On Thu, Dec 3, 2015 at 4:47 PM, Dirk Jagdmann wrote:
> I'm currently looking at https://www.sqlite.org/autoinc.html
>
> I suggest you change "You can access the ROWID of an SQLite table using
> one {of} the special column names..." and insert the word "of".
>
> --
> ---> Dirk Jag
I understand Smith's point. But when I am sure that some schema is
going to stay in SQLite for the foreseeable future, I like using text.
It is simple, adequate, and expresses my intent completely: TEXT.
That's what the column has, TEXT, not 40, not 60, not less than 30,
just freaking text.
Lastly
You shouldn't need to back up the shm file as this will be recreated if needed.
You naming convention is also off, you mean
mydatabase.sqlite-journal
mydatabase.sqlite-wal
mydatabase.sqlite-shm
so mydatabase.sqlite* would be what's required (which would include
the unneeded shm file).
Paul
www.
On 2015/12/03 3:04 AM, Scott Hess wrote:
> I discourage this kind of usage because it means that in some distant
> future when someone has to make things work with a different database
> engine, they have to grind through and check every weirdo VARCHAR(73) and
> MEDIUMBIGINT declaration someone p
On 3 Dec 2015, at 10:17am, Murdare, Vijaykumar S (GE Oil & Gas)
wrote:
> 1) If read operation is in progress, then can I take backup safely with
> file copy or any other third party tool?
When taking a backup of the database file you should also copy all other files
with similar names i
On 3 Dec 2015, at 12:49pm, R Smith wrote:
> I *ALWAYS* write cross-platform code as far as SQL is concerned. I even think
> in this day and age every programmer should, or is there a case for the
> opposite?
If cross-platform code worked identically cross-platform I'd rest more easily.
The
So, it will be quite a rare occurrence then that this could be of any
benefit.
Still nice to know this.
RBS
On 3 Dec 2015 1:33 am, "Richard Hipp" wrote:
> On 12/2/15, Bart Smissaert wrote:
> >> and the SQLite query planner sometimes notes that length when
> considering
> > data shape
> >
> >
On Thu, Dec 3, 2015 at 4:49 AM, R Smith wrote:
> On 2015/12/03 3:04 AM, Scott Hess wrote:
>
>> I discourage this kind of usage because it means that in some distant
>> future when someone has to make things work with a different database
>> engine, they have to grind through and check every weird
I'm currently looking at https://www.sqlite.org/autoinc.html
I suggest you change "You can access the ROWID of an SQLite table using
one {of} the special column names..." and insert the word "of".
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
Hi,
Also, I would like to know while taking the backup of online databases:
1) If read operation is in progress, then can I take backup safely with
file copy or any other third party tool?
2) If my application made the changes and committed the changes to SQLite
and immediately after
On 12/3/15, Murdare, Vijaykumar S (GE Oil & Gas)
wrote:
> Hi,
>
> Also, I would like to know while taking the backup of online databases:
>
> 1) If read operation is in progress, then can I take backup safely with
> file copy or any other third party tool?
Yes.
>
> 2) If my application
On 2015/12/02 6:34 PM, Erwin Kalvelagen wrote:
> Good morning.
>
> I wrote a little tool to dump certain data sets into a SQLite database. A
> user suggested that I should not use type TEXT but rather type VARCHAR for
> character columns, due to some issue with Excel/VBA. See the comments in:
> h
> and the SQLite query planner sometimes notes that length when considering
data shape
In what situations does that happen?
RBS
On Thu, Dec 3, 2015 at 12:29 AM, R Smith wrote:
>
>
> On 2015/12/02 6:34 PM, Erwin Kalvelagen wrote:
>
>> Good morning.
>>
>> I wrote a little tool to dump certain da
14 matches
Mail list logo