[Vtigercrm-developers] Receiving data from outside sources

[Michel JACQUEMES]

Hi Mike & Dan,

I have also thought a bit about that because the project I am working on has
some requirements.

> -----Message d'origine-----
> De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-
> developers-bounces at lists.vtigercrm.com] De la part de Mike Fedyk
> Envoyé : mardi 28 février 2006 02:49
> À : dan.means at teamsrs.com; vtigercrm-developers at lists.vtigercrm.com
> Objet : Re: [Vtigercrm-developers] Receiving data from outside sources
> 
> Dan Means wrote:
> 
> > This is a place that I've been working with clients on -- the idea of
> > a CSV import is fine -- when you have a few hundred items to import,
> > but not much more.
> 
> My post was really in response to two different topics and should be
> looked at that way.
>

I agree, there are 2 different systems. Importing and exporting csv files
suppose that the user is managing the process. That is useful to initialize
a database or to modify a lot of data when you have not any SQL knowledge to
write queries.
Syncing 2 databases (or more) suppose that 2 systems are speaking together,
are able to control that each other has understood what the other asked for
and if the job has been achieved. This without any human control. 

> We have some parts where we don't even support import at all.  That is a
> problem and CSV import is the first step in the right direction.
> 
> >
> > As an example, we've had to create several timed scripts for a client,
> > to feed information from an MSSQL based ERP (Accountmate) system into
> > Vtiger -- and do a little synching also of things like inventory on
> > hand etc. I gave up on the forums when basic questions like what is
> > the use of the foreign key constraints went un-answered -- and my
> > discovery -- they don't to anything presently.....
> 
> Which foreign keys?
>

Foreign keys don't have to be a problem, vtigercrm must be in charge of
database integrity. Interface should be something like:

	my_contact = new contact();
	// populate contact data
	my_contact->save();

without knowing if data is parsed into several tables. This means also a
prerequisite, we have to manage transactional updates. The system has to
backout all the syncing process in case of failure because it cannot know if
the entire data is coherent or not.
 
> >
> > There's all sorts of limits and issuses messing with CSV data, size of
> > upload files allowed etc.
> >
> > When you're dealing with thousands of accounts, thousands of products,
> > hundreds of orders - you have to perform direct inserts into
> somewhere....
> 
> Our installation would only have maybe 100 records for demo data.  This
> is an optimal use for CSV.
> 
> I agree that using CSV to interact with another system would not be a
> good solution if there are a lot of records being transferred.
> 
> Mike

I had also in mind this kind of feature when I posted the mail about PDA
syncing, it was a first step. The main feature is to separate protocol
dialog and object manipulation, I open a sync dialog with one datasource
(e.g. tasks, contacts, notes...). But it is not for 4.2.5, maybe later?

Michel