Guido Seifert schreef op 4-2-2015 om 15:37:
> Never used it myself. But if I needed to secure an sqlite db, I would look
> into SQLCipher:
>
> https://www.zetetic.net/sqlcipher/
>
> Guido
> ___
> Interest mailing list
> Interest@qt-project.org
> http://l
> On Feb 4, 2015, at 7:51 AM, Graham Labdon
> wrote:
>
> Hi
> I am just starting to explore Qt support for databases and have this as a
> first attempt to open a data base
> QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
> db.setHostName("bigblue");
> db.setDatabaseN
Never used it myself. But if I needed to secure an sqlite db, I would look into
SQLCipher:
https://www.zetetic.net/sqlcipher/
Guido
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Den 04-02-2015 kl. 15:18 skrev alexander golks:
> Am Wed, 4 Feb 2015 15:01:50 +0100
> schrieb Till Oliver Knoll :
>
>>
>>
>>
>>> ...
>>> QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
>>> ...
>>> bool ok = db.open();
>>>
>>> When I run this ok is always true, no matter what argumen
On 04.02.2015 22:18, alexander golks wrote:
> Am Wed, 4 Feb 2015 15:01:50 +0100
> schrieb Till Oliver Knoll :
>
>>
>>
>>
>>> ...
>>> QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
>>> ...
>>> bool ok = db.open();
>>>
>>> When I run this ok is always true, no matter what arguments
Am Wed, 4 Feb 2015 15:01:50 +0100
schrieb Till Oliver Knoll :
>
>
>
>
> > ...
> >QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
> > ...
> >bool ok = db.open();
> >
> > When I run this ok is always true, no matter what arguments are passed.
>
> I am not experienced with SQLIT
> ...
>QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
> ...
>bool ok = db.open();
>
> When I run this ok is always true, no matter what arguments are passed.
I am not experienced with SQLITE, but is it possible that each time a new DB
instance (file) is created, if no such i
> Am 04.02.2015 um 14:51 schrieb Graham Labdon
> :
>
> ...
>db.setUserName("acarlson");
>db.setPassword("1uTbSbAs");
Those are not your real credentials, right? *Right*?
;)
Cheers,
Oliver
___
Interest mailing list
Interest@qt-project.org
h
Hi
I am just starting to explore Qt support for databases and have this as a first
attempt to open a data base
QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
db.setHostName("bigblue");
db.setDatabaseName("flightdb");
db.setUserName("acarlson");
db.s
On quinta-feira, 23 de janeiro de 2014 10:23:51, André Somers wrote:
> > http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
>
> If I understand it correctly, the slow mode Thiago was telling about is
> the one that provides the behavior that Philipp was asking about, right?
It is. I
Yes it seems so. Maybe that's why we still not use it Qt5.
On Thu, Jan 23, 2014 at 10:23 AM, André Somers wrote:
> Bo Thorsen schreef op 23-1-2014 9:39:
> > http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
> If I understand it correctly, the slow mode Thiago was telling about is
> t
Bo Thorsen schreef op 23-1-2014 9:39:
> http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
If I understand it correctly, the slow mode Thiago was telling about is
the one that provides the behavior that Philipp was asking about, right?
André
>
> Den 23-01-2014 09:24, Philipp Kursawe sk
http://qt-project.org/doc/qt-5/qmutex.html#RecursionMode-enum
Den 23-01-2014 09:24, Philipp Kursawe skrev:
> To be re-entrant from the same thread. We have the case that functions
> running in the same thread can each ask for the DB connection. That
> should still be allowed.
>
>
> On Thu, Jan 23,
To be re-entrant from the same thread. We have the case that functions
running in the same thread can each ask for the DB connection. That should
still be allowed.
On Thu, Jan 23, 2014 at 8:46 AM, Thiago Macieira
wrote:
> On quinta-feira, 23 de janeiro de 2014 05:54:36, Philipp Kursawe wrote:
>
On quinta-feira, 23 de janeiro de 2014 05:54:36, Philipp Kursawe wrote:
> Does it support the behaviour of std::recursive_mutex?
What behaviour, in specific?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description
Ah that explains it! Thanks for the benchmarks. We only tested it with the
old 4.8 implementation and decided to go with std::mutex instead. We might
check out QMutex again!
Does it support the behaviour of std::recursive_mutex?
On Wed, Jan 22, 2014 at 11:16 PM, Thiago Macieira wrote:
> On quar
On quarta-feira, 22 de janeiro de 2014 22:01:39, Philipp Kursawe wrote:
> sorry got that mixed up. Qt uses Events under Windows (was that changed in
> Qt5?), which is still not as efficient as CriticalSections.
Yes, QMutex got a large rewrite in Qt 5.
I'd like to see your benchmarks. This is what
sorry got that mixed up. Qt uses Events under Windows (was that changed in
Qt5?), which is still not as efficient as CriticalSections.
On Wed, Jan 22, 2014 at 5:11 PM, Thiago Macieira
wrote:
> On quarta-feira, 22 de janeiro de 2014 16:52:22, Philipp Kursawe wrote:
> > The Win32 implementation us
On quarta-feira, 22 de janeiro de 2014 16:52:22, Philipp Kursawe wrote:
> The Win32 implementation uses a mutex, which is used for inter-process
> sync. Inside a process its a waste. Better use CriticalSection, its a
> kernel object and several times faster then a mutex on Win32.
I'm sorry, but th
The Win32 implementation uses a mutex, which is used for inter-process
sync. Inside a process its a waste. Better use CriticalSection, its a
kernel object and several times faster then a mutex on Win32.
On Wed, Jan 22, 2014 at 4:45 PM, Thiago Macieira
wrote:
> On quarta-feira, 22 de janeiro de 2
On quarta-feira, 22 de janeiro de 2014 18:48:53, Soroush Rabiei wrote:
> A connection can only be used from within the thread that created it.
> Moving connections between threads or creating queries from a different
> thread is not supported.
> My question is how can I make connections between UI
On quarta-feira, 22 de janeiro de 2014 16:39:24, Philipp Kursawe wrote:
> Your database class uses a std::recursive_mutex (not the Qt mutex, its a
> resource waster!)
Do you have any numbers? QMutex is very small and optimised (on Linux).
QWaitCondition suffers because QMutex is so small.
--
Thi
Your database class uses a std::recursive_mutex (not the Qt mutex, its a
resource waster!) to synchronize access to the database.
Then in the method that returns a new shared pointer of QSqlDatabase you
use a std::lock_guard with that mutex to allow only one thread to use the
DB. I usually also ass
Hi
I'm writing a data-intensive application which must wait for large chunks
of data from a remote database, sometimes about 10 seconds. So I want to
keep UI in main thread (which one is running event loop) and move all data
operations to other threads. I can see how to connect signals/slots from
Hello,
Be careful of mixing thread and mysql :
https://bugreports.qt-project.org/browse/QTBUG-31468
You should protect the calls to addDatabase with a mutex.
Le 30/05/2013 18:31, Karl Ruetz a écrit :
Both the documentation and my own experience say what you are after is
not possible:
htt
> On Thursday 30 May 2013 18:03:15 Witold E Wolski wrote:
>
>
> I am using threading to speed up compuation. Each thread produces some
> results which I would like to store in a sqlite file.
>
>
>
> My idea is to have something like an monitor object which has an
> QSqlDatabase member and a i
In the case that your computation is massive, you may want to change your
concurrency design. You can add a writer thread to be the only one who
talks to database. Other threads write their manipulated data into a
mutex-guarded shared data structure (say a queue). Then the writer thread
can write d
Both the documentation and my own experience say what you are after
is not possible:
http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-the-sql-module
I do a similar thing only with MySQL. I am forced to create a
QSqlDatabase object with each thread. If I do not, I get dead lo
AFAIK what you are trying is not possible:
http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-the-sql-module
Best,
Lorenz
Am 30.05.2013 18:03, schrieb Witold E Wolski:
> I am using threading to speed up compuation. Each thread produces some
> results which I would like to store in
I am using threading to speed up compuation. Each thread produces some
results which I would like to store in a sqlite file.
My idea is to have something like an monitor object which has an
QSqlDatabase member
and a insert method which is synchronized using a mutex.
The problem I am actually run
On 5/8/2013 1:46 AM, Andre Somers wrote:
> Op 7-5-2013 18:06, Duane schreef:
>>
>> I don't think this is a Qt error, nor an error in our apps as nothing
>> has chanced in them. I'm assuming it something else affecting the
>> server. We aren't the only application on this database. I need some
>>
Op 7-5-2013 18:06, Duane schreef:
>
> I don't think this is a Qt error, nor an error in our apps as nothing
> has chanced in them. I'm assuming it something else affecting the
> server. We aren't the only application on this database. I need some
> way to find what is causing it. I am adding so
On 5/7/2013 11:30 AM, Thiago Macieira wrote:
> On terça-feira, 7 de maio de 2013 09.10.36, Duane wrote:
>> I haven't checked LastError but I did check the MySql log and there were
>> no errors. I will add some debugging that dumps the last error.
>> I don't think it's a corrupted table or anything
On terça-feira, 7 de maio de 2013 09.10.36, Duane wrote:
> I haven't checked LastError but I did check the MySql log and there were
> no errors. I will add some debugging that dumps the last error.
> I don't think it's a corrupted table or anything because I would get
> errors for that and also, j
On 5/6/2013 5:01 PM, Karl Ruetz wrote:
> Did you check QSqlDatabase::lastError()? Might give you a clue. I'd also
> check any logs generated by the DBMS to see if a table has become
> corrupted or some such thing.
>
> Karl
>
> On 2013-05-06 13:00, Duane wrote:
>
>> Why would bool QSqlDatabase::tran
Did you check QSqlDatabase::lastError()? Might give you a clue. I'd
also check any logs generated by the DBMS to see if a table has become
corrupted or some such thing.
Karl
On 2013-05-06 13:00, Duane wrote:
> Why would bool QSqlDatabase::transaction ()
> return false? I have a
system that
It's driver-dependent. You might want to check what
QSqlDatabase::lastError() returns or look at the code of the driver you
use, find the function/query used to begin a transaction and read the
actual library/RDBMS documentation.
On May 6, 2013 11:00 PM, "Duane" wrote:
> Why would bool QSqlDataba
Why would bool QSqlDatabase::transaction ()
return false? I have a system that has been running for
years and recently, intermittently calls to this function have been failing.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.o
Do you say QStringList QSqlDatabase::connectionNames ()
returns anything after QSqlDatabase::close is called?
I believe in Qt 4.6 it worked on Windows.
You may try QSqlDatabase::removeDatabase
but it may cause some resource leeks if there are open queries.
Regards,
Alex
On Thu, Ap
In Qt 4, is there a way to FORCE close all sql database connections...
Use sqlite, even calling QSqlDatabase::close does not cause all connections to
close...
Any thoughts on forcing it to just close every connection...
Scott
___
Interest mailing list
On Mon, 4 Mar 2013 09:49:35 +
wrote:
> Not enough info in the backtrace. Hrm. I did see this many years ago,
> but I can't remember what caused it. Some form of being a bit too smart
> for my own good I suspect ;)
>
> Exact line in the destructor could help. Are you deriving from the
> QSqlDa
...@qtrac.plus.com; interest@qt-project.org
Subject: Re: [Interest] QSqlDatabase segfault - me or Qt5?
Not enough info in the backtrace. Hrm. I did see this many years ago, but I
can't remember what caused it. Some form of being a bit too smart for my own
good I suspect ;)
Exact line i
] On Behalf Of
> ext Mark Summerfield
> Sent: Friday, 1 March 2013 3:24 PM
> To: interest@qt-project.org
> Subject: [Interest] QSqlDatabase segfault - me or Qt5?
> Importance: High
>
> Hi,
>
> I've got a release version of Qt that's giving this on 64-bit linux:
Hi,
I've got a release version of Qt that's giving this on 64-bit linux:
Program received signal SIGSEGV, Segmentation fault.
0x77bb35ea in QSqlDatabase::close() ()
from /home/mark/opt/qt501/lib/libQt5Sql.so.5 (gdb) bt
#0 0x77bb35ea in QSqlDatabase::close() ()
from /home/mark/opt
Hello,
can be for this:
/ / This is needed for oracle oci When compiling with mingw-w64 headers
# if defined (__MINGW64_VERSION_MAJOR) && defined (_WIN64)
# define __ int64 _int64
# endif
in the src/sql/drivers/oci/qsql_oci.cpp
It works in visual studio to 64 bits. And I have also tested in
On sexta-feira, 20 de abril de 2012 10.04.36, salome...@terra.es wrote:
> This is a part of my code:
>
> QStringList qlis = QSqlDatabase::drivers();
> if (qlis.contains("QOCI")) MemLogs->append("It has QOCI");
> QApplication::processEvents();
> AdcConexionBD = QSqlDataba
This is a part of my code:
QStringList qlis = QSqlDatabase::drivers();
if (qlis.contains("QOCI")) MemLogs->append("It has QOCI");
QApplication::processEvents();
AdcConexionBD = QSqlDatabase::addDatabase("QOCI", "oracle");
MemLogs->append("after of QOCI");
QApp
Am 19.04.2012 14:42, schrieb salome...@terra.es:
> When I run my application compiled with Visual Studio works without
> problem, but when I run my application compiled with MinGW when it
> gets to that point it stops working.
What returns QSqlDatabase::drivers() when you use MinGW? Is there a
Hello,
Why don´t work QSqlDatabase::addDatabase ("QOCI") in MinGW 64-bit and if it
works in Visual Studio 2008 to 64-bit?.
When I run my application compiled with Visual Studio works without problem,
but when I run my application compiled with MinGW when it gets to that point it
stops working
49 matches
Mail list logo
