Hi Everyone,

I've installed SugarCRM and had a bit of a play around with it. It looks at first glance to be a very useful system, but a couple of things raised alarm bells.

The first thing I thought I would do is randomly play with a bit of data. I created a project, some project tasks just to show the team here some of the capabilities (and, of course, learn it myself). I figured we'd get some better results if I imported some data from our current home-made CRM system.

So, I deleted the project. It appeared that the project tasks were not deleted. I'd expect this to be either taken care of by a database constraint, or instead by code. I'm not ruling out me doing something wrong here and would surely appreciate any comments.

Continuing on with my plans, I started with an Accounts import. I mapped in some accounts using the import wizard, which all seemed to work well - but it fell over with a field length error (SQL error, not a system error). At this point, the import was half-completed.

A couple of observations:

1. You'd expect the system to validate the data before importing to avoid a crash.
2. In the event of a crash, you would expect the database to rollback to transaction to maintain database integrity.

(1) is very important in the absence of proper transactional control. For me it wasn't much of an issue but I have clients with 10s of thousands of contacts - a part import like this would have been difficult to resolve.

I did notice the rollback import button, but this was only available when the import had not crashed due to a data error.

Moving on, I deleted the accounts and tried again. I figured a nice approach would be to do an export (to get the fieldnames) and then transform my data in Excel to make the import easier. Even though I had the fieldnames corresponding to the field names in the export, I still had to manually map the fields. That's not a major issue, but a nice bit of attention to detail would have been to auto-map fields based on field names.

This might well be due to limitations of MySQL. Our existing system uses Firebird as the database (Open Source, transactional, and cross-platform) - if the limitation is due to MySQL we'd be happy to participate in a conversion to also support Firebird.



Mike