forms and native SQL

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

forms and native SQL

Oliver Peters-2
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.

Oliver


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

Reply | Threaded
Open this post in threaded view
|

Re: forms and native SQL

Ocke Janssen-2
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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: forms and native SQL

Oliver Peters
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.

greetings (to hamburg?) from elmshorn
Oliver

-----Urspr√ľngliche Nachricht-----
Von: "Ocke Janssen" <[hidden email]>
Gesendet: 12.11.2010 09:51:27
An: [hidden email]
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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
___________________________________________________________
Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02

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

Reply | Threaded
Open this post in threaded view
|

Re: forms and native SQL

Ocke Janssen-2
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"<[hidden email]>
> Gesendet: 12.11.2010 09:51:27
> An: [hidden email]
> 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
>>>
>>>

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