summaryrefslogtreecommitdiff
path: root/libopie/pim/ocontactaccessbackend_sql.cpp
Side-by-side diff
Diffstat (limited to 'libopie/pim/ocontactaccessbackend_sql.cpp') (more/less context) (show whitespace changes)
-rw-r--r--libopie/pim/ocontactaccessbackend_sql.cpp5
1 files changed, 4 insertions, 1 deletions
diff --git a/libopie/pim/ocontactaccessbackend_sql.cpp b/libopie/pim/ocontactaccessbackend_sql.cpp
index a5be4c8..d20df56 100644
--- a/libopie/pim/ocontactaccessbackend_sql.cpp
+++ b/libopie/pim/ocontactaccessbackend_sql.cpp
@@ -5,24 +5,27 @@
*
* =====================================================================
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
* =====================================================================
* =====================================================================
* Version: $Id$
* =====================================================================
* History:
* $Log$
+ * Revision 1.5 2004/03/14 13:50:35 alwin
+ * namespace correction
+ *
* Revision 1.4 2003/12/22 10:19:26 eilers
* Finishing implementation of sql-backend for datebook. But I have to
* port the PIM datebook application to use it, before I could debug the
* whole stuff.
* Thus, PIM-Database backend is finished, but highly experimental. And some
* parts are still generic. For instance, the "queryByExample()" methods are
* not (or not fully) implemented. Todo: custom-entries not stored.
* The big show stopper: matchRegExp() (needed by OpieSearch) needs regular
* expression search in the database, which is not supported by sqlite !
* Therefore we need either an extended sqlite or a workaround which would
* be very slow and memory consuming..
*
@@ -48,25 +51,25 @@
#include <qstringlist.h>
#include <qpe/global.h>
#include <qpe/recordfields.h>
#include <opie/ocontactfields.h>
#include <opie/oconversion.h>
#include <opie2/osqldriver.h>
#include <opie2/osqlresult.h>
#include <opie2/osqlmanager.h>
#include <opie2/osqlquery.h>
-
+using namespace Opie::DB;
// If defined, we use a horizontal table ( uid, attr1, attr2, attr3, ..., attrn ) instead
// vertical like "uid, type, value".
// DON'T DEACTIVATE THIS DEFINE IN PRODUCTIVE ENVIRONMENTS !!
#define __STORE_HORIZONTAL_
// Distinct loading is not very fast. If I expect that every person has just
// one (and always one) 'Last Name', I can request all uid's for existing lastnames,
// which is faster..
// But this may not be true for all entries, like company contacts..
// The current AddressBook application handles this problem, but other may not.. (eilers)