(*** This bug was imported into bugs.kde.org ***) Package: kab Version: v2.0 (KDE 2.0.1) Severity: wishlist Compiler: gcc version 2.95.2 19991024 (release) OS: Linux 2.2.16 i686 (SuSE) hi i'm using php/mysql to manage my adresses yet it pisses me off having to enter name and email-adress of each new contact into the kde2 adressbook to use it with kmail couldn't there be support for sql-databases to tell the kde2-adressbook what database (including host/port login/password) to use then create some kind of map which tells the adressbook which field in the db-table contains which information so that kab would get the information from the database in the future?
We are working on a sql support at the moment. The stable version will get released with KDE3.2 Ciao, Tobias
What's going on with the SQL support? :-) My, and the most other Firms, Customers adresses are stored in a DB. It will be some more komfortable to get the emailadress from there. I'm using KDE 3.2, but i can't find.....
On Wed, Mar 17, 2004 at 12:21:43AM -0000, Herbert Kozuschnik wrote: Hi Herbert, > What's going on with the SQL support? :-) Well, nobody worked on it at the moment. > My, and the most other Firms, Customers adresses are stored in a DB. > It will be some more komfortable to get the emailadress from there. The problem of this resource is, that you have to find a mapping schema to handle different database and table structures. Ciao, Tobias
isn't it possible to handle the DB-connection like OpenOffice.org it does?
maybe by qt-sql plugin? (http://doc.trolltech.com/3.3/sql.html) sql table == ldap's fields.
In Bug 72653, I just aired the idea of using RDF as a complete backend. Since RDF has gained a RDF/XML representation of vCard, and there are well developed ways to store RDF in SQL databases, and RDF representation of the KAddressbook data seems like a good idea to me... One could make different layers: KAddressbook works on RDF data, which can be stored on file as e.g. RDF/XML or saved to an SQL backend. Since more KDE apps (and the rest of the web) could use RDF, one could effectively decouple the storage from the app...
Just to make it clear: What we are talking about (and what I would need urgently) is binding an EXISTING sql-db as a resource to KAB. ad "find a mapping schema": Well, maybe this sounds a bit naive but I cannot see the difficulty. On one side you have the fields KAB needs On the other side you have the fields the existind SQL-DB provides So, when adding the resource "SQL-DB" to KAB, simply store SERVER,PORT,DBNAME,TABLENAME and a KAB<->SQL field mapping. And it should work. Or am I missing something?
On Mon, Nov 29, 2004 at 09:37:31AM -0000, Norbert Zawodsky wrote: Hi Norbert, > Well, maybe this sounds a bit naive but I cannot see the difficulty. > On one side you have the fields KAB needs > On the other side you have the fields the existind SQL-DB provides > So, when adding the resource "SQL-DB" to KAB, simply store SERVER,PORT,DBNAME,TABLENAME > and a KAB<->SQL field mapping. And it should work. Or am I missing something? Every entry needs a unique ID, does all databases provide that? Are all fields in the same table or distributed over the whole DBMS? How to handle proper locking? etc. etc. It's not that easy what it look like. But you can always convince me of the opposite with a patch :) Ciao, Tobias
Am Montag, 29. November 2004 15:19 schrieb Tobias König: > Every entry needs a unique ID, does all databases provide that? Are all A properly designed DB should provide this. And I think that KAB can name this an requierement. > fields in the same table or distributed over the whole DBMS? How to I agree that this is a bit more complicated. But I could easily live with the restriction that all fields must be in one table. At least for a start. > handle proper locking? etc. etc. Does KAB poper locking now? I mean, can multiple users acess the same resource? If yes, then proper locking should already exist somewhere inside KAB. Ciao, Norbert
I am advertising using KexiDB, KDE db layer for accessing SQL data sources. COntact me for further discussion.
Hi there. Linux and spec. KDE shut be go more and more to the business desktop. That will only be if there cooperate funktions, futures and look a likes. I use linux an kde in my business and it's horrible to convert information bedween the different software and normaly not practible. In my company with more than 100 users it's a KO criteria to use linux and kde on the desktop. And i think there are very more users and companys with the same problem. in short: it is more than time to have an native or odbc conectivity th sql-source like mysql. hans
KexiDB bindings (SQLite, MySQL, PostgreSQL out of the box) are planned for the whole Kontact suite. More info: kexi-project.org
I see that the KAddressBook manual at <http://docs.kde.org/development/en/kdepim/kaddressbook/introduction.html> says: ------------------------------------------------------ Since it is based on the kabc library it supports resources, which can be used to load and save your contacts to many different locations — not just the local file system, but also to LDAP servers and SQL databases. ------------------------------------------------------ But I didn't see anything further about SQL.
http://pim.kde.org/akonadi/ should make things easier.
You should just add a simple module for set-up a MySQL connection that way administrators and other developers could easly works with the PIM
When akonadi will be ready, this feature will be available :-)
The development of the old KAddressBook will be discontinued for KDE 4.4. Since the new application has the same name, but a completly new code base we close all bug reports against the old version and ask the submitters to resend there reports against the new product.