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--