I've used ACT in the past but not the 2008 version. It's a nice CRM but as Liebling mentioned, it has a propietary database. If the 2008 version is SQL Server based, my guess (from ACT's track record) is that it's probably designed so it's difficult to decipher the database and easily merge it with other databases (just guessing from working with ACT in the past.) If the 2008 SQL Server based version is in a nice, straight-forward, relational table structure, I think it's a good product to consider (and as Liebling also mentioned, Goldmine is another consideration.) ACT is still a CRM though and I've designed similar CRM programs (SQL Server based) which satisfied the needs of the company even though they didn't have all the features ACT did. If you need all the features of a CRM, I would consider some of the options Liebling gave. If you don't need all the features, you might want to consider designing your own CRM which will most likely offer you a lot more flexibility on design and also with merging with your other databases.
The CRM I designed was in an MSAccess mdb front-end (with SQL Server back-end tables linked into the mdb). We used Citrix for external connections and it worked extremely well. I designed the Forms in Access for the CRM unbound (so it was lightning fast with over 2 million records.) I liked this setup because Access offered the benefits of flexibility, ease of design, and ability to quickly create/modify the front-end interface (Access ADP's are more difficult to work with and take twice as long to develop verses an Access mdb file.) Having SQL Server as the back-end avoided the restrictions MSAccess tables have and MSAccess has the ability to design some really great reports (in my opinion - I think MSAccess reports are easier and quicker to design (again - mdb) verses any other program and comparable to Crystal Reports.) But again, this is in an mdb file with SQL Server linked tables. An ADP is more difficult to work with and you don't have the benefit of creating quick, easy queries like you do with an mdb.
Before you get rid of Access, you may want to consider designing mdb files with linked SQL Server tables verses ADP's. I designed the entire midwest Energy Conservation programs in Access mdb's (front-end) and SQL Server linked tables (over 5 million records in all the db's.) All the problems you read about with Access are due to having Access tables in a multi-user environment and large recordsets. If you utilize mdb's and SQL Server linked tables, those problems go away. Also, utilizing unbound forms in an mdb and writing functions to retrieve, write/update, and delete records is basically the same as an ADP but easier to work with (and you also have the power of designing Access queries very quickly). If you design your unbound forms this way, Access is really no different than any other programming tool (except that it's easier!) I was the Manager of the Database Applications department and looked at the ease of designing, modifying, and maintaining the system verses purchasing a 3rd party application which still needed customization (or designing in another front-end language). Developing new Energy Conservation programs happened very fast with Access as the front-end (I would start with Access tables and the upsizing wizard of Access tables to SQL Server tables works very well.) I'm not sure as to why you've decided to do away with Access but if you're designing ADP's, I wouldn't judge Access based on them. ADP's are simply not easy to work with and you can accomplish the same thing with unbound forms in an mdb. Even bound forms in an mdb works very well if designed correctly and is really no different than designing forms in other programming tools. I designed some of the large SQL Server tables with bound forms in mdb's which performed better than those developed in other languages.
Last edited by pkstormy; 09-19-07 at 00:43.
Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)