Re: forms and native SQL

Ocke Janssen <[email protected]> Wed, 17 Nov 2010 07:25:14 +0100
Newsgroups gmane.comp.openoffice.dba.user
Message-ID <[email protected]>
--------------000907020401040003030906
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Oliver,

On 12.11.2010 11:46, Oliver Peters wrote:
> Hello Ocke,
>
> thanks for your hints but you don't make me happy because I need to do date and time arithmetics and that is nothing I can do with standard SQL (whatever this is) afaik.
> My problem is that I decided to use unix epoc as timestamps in my sqlite db because it needs much lesser space than i.e. "YYYY-MM-DD HH:MM:SS". I do a lot of logging so I gain much space by using epoc.
So the best would be to create an issue and you attach a sample db which 
contains the sql statements. May be we have an issue in our parser or we 
need to enhance the parser once again ;-)
>
> greetings (to hamburg?) from elmshorn
Yes, Hamburg.

Best regards,

Ocke
> Oliver
>
> -----Ursprüngliche Nachricht-----
> Von: "Ocke Janssen"<[email protected]>
> Gesendet: 12.11.2010 09:51:27
> An: [email protected]
> Betreff: Re: [dba-users] forms and native SQL
>
>> Moin Oliver,
>>
>> On 11.11.2010 23:52, Oliver Peters wrote:
>>> Hello,
>>>
>>> I'm working with sqlite 3.7.3 as an external db via ODBC
>>> (http://www.ch-werner.de/sqliteodbc/) under WinXP.
>>>
>>> My frontend is OOo Base (330 RC4). For inserting and updating tables I
>>> use forms. If I choose SQL as a datasource for the form and don't allow
>>> OOo to check the SQL (because I use sqlite specific constructs) I can't
>>> insert or update anymore. The same with "ordinary" queries. I feel(!)
>>> that this is a wanted behaviour that is reproducable with other dbs
>>> (PostgreSQL, MySQL,...) but I can't explain why this should be
>>> necessary.
>>>
>>> Any hints/coaching are/is appreciated.
>> The reason is that we need to uniquely identify a row. This is done by
>> fetching the primary key column(s). When we now can't parse the SQL
>> statement how should we know that all primary key column(s) are part of
>> the select. And how they are named. As work around I would try to
>> convert the sqlite specific constructs to standard SQL where possible.
>>
>> Best regards,
>>
>> Ocke
>>>
>>> Oliver
>>>
>>>


--------------000907020401040003030906
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--------------000907020401040003030906--