Diffstat (limited to 'libopie/pim/ocontactaccessbackend_sql.cpp') (more/less context) (show whitespace changes)
-rw-r--r-- | libopie/pim/ocontactaccessbackend_sql.cpp | 5 |
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 @@ -1,32 +1,35 @@ /* * SQL Backend for the OPIE-Contact Database. * * Copyright (c) 2002 by Stefan Eilers (Eilers.Stefan@epost.de) * * ===================================================================== * 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.. * * Revision 1.3 2003/12/08 15:18:10 eilers * Committing unfinished sql implementation before merging to libopie2 starts.. * * Revision 1.2 2003/09/29 07:44:26 eilers @@ -44,33 +47,33 @@ #include "ocontactaccessbackend_sql.h" #include <qarray.h> #include <qdatetime.h> #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) #define __USE_SUPERFAST_LOADQUERY /* |