Bug 18198

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.