ACT Premium 2008

Hi all I have a question, has anyone tried the new ACT Premium 2008 apparently it runs off of SQL Server and can support 31-50 Users.
Has anyone tried it??
We are trying to get rid of Access and have a database that has a customizeable front end and will run off SQL Server 2005Nope, sorry, we build custom solutions

http://www.act.com/2008/system/|||So do you guys have a website??|||Act! and GoldMine are very similar products, and are CRM solutions. But the drawback to both programs is a highly propietary system, which limits reporting to canned reports and the application itself. Integrating Act! requires a lot of consulting work, as massaging the data in isn't as easy as it could be because the table structures are not clearly defined. Most companies pay a lot of money to consultants who specialize in these two products because of it's complexity.

Act! does work on SQL, but making sense of what it's all doing requires a lot of training.

There are CRM solutions that are easier to administer and maintain, like Siebel Sales and Microsoft's own CRM, and a lot more support for those products in an enterprise environment. If you have 31-50 users, you'll want to aim high in your steering and look at the bigger picture. An unhappy sales staff is detrimental to your business as a whole, and the learning curve with both Act! and Goldmine client side is a big step that can cause a lot of headaches.|||So do you guys have a website??

http://www.prudential.com

However most of the apps we write are intranet...but it's a world wide intranet

the last one might exposed..I have to check|||That would be the back end what we are trying to do is have a front end thats user friendly and some what customizeable without allot of programming. A web interface would be nice but optional. We are trying to get off the ADP'S (Ms Access as front end)

Thats we were looking at ACT Premium 2008

You mentioned Microsoft's CRM's?? Whats the names of them|||http://www.microsoft.com/dynamics/crm/default.mspx|||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.

Accounting procedure

Hi,
I have the following procedure that I am trying to run on a data warehouse -
it is supposed to increase or decrease the running premium balance and the
fire fee balance based on the type of transaction, but it seems to just be
increasing the running balance - do you see where I am going wrong?
Thanks in advance
-- Local Variables
DECLARE
@.PolicyKeyID INT,
@.Policy_Number VARCHAR (10),
@.Trans_Type VARCHAR(40),
@.Billed_Premium DECIMAL(10,2),
@.Billed_Fire_Fee DECIMAL(10,2),
@.Pymt_Recvd DECIMAL(10,2),
@.SC_Recvd DECIMAL(10,2),
@.Transcode VARCHAR (4),
@.Portfolio_Set VARCHAR (4),
@.Type VARCHAR (25),
@.Typecode VARCHAR (4),
@.Previous_Policy_Number VARCHAR (10),
@.Running_Premium DECIMAL(10,2),
@.Running_Fire_Fee DECIMAL(10,2),
@.Error_Code_Tran INT,
@.Error_Code_Proc INT,
-- CONSTANTS declared for Transaction Types
@.NEW_BILL VARCHAR(15),
@.RENEWAL VARCHAR(20),
@.CANCELLATION VARCHAR(35),
@.CHANGE VARCHAR(15),
@.CASH_WITH_APP VARCHAR(25),
@.RETURNED_CHECK VARCHAR(35),
@.PAYMENT VARCHAR(35),
@.PYMT_REVERSAL VARCHAR(25),
@.DISBURSEMENT VARCHAR(25),
@.CANCEL_DISBURSEMENT VARCHAR(35)
-- Assign CONSTANTS
SET @.NEW_BILL = 'New'
SET @.RENEWAL = 'Renewal'
SET @.CANCELLATION = 'Cancellation'
SET @.CHANGE = 'Change'
SET @.CASH_WITH_APP = 'Cash With App'
SET @.RETURNED_CHECK = 'Returned Check'
SET @.PAYMENT = 'Payment'
SET @.PYMT_REVERSAL = 'Payment Reversal'
SET @.DISBURSEMENT = 'Disbursement'
SET @.CANCEL_DISBURSEMENT = 'Cancel Disbursement'
-- Set Error Codes
SET @.Error_Code_Tran = 0
SET @.Error_Code_Proc = 0
SET NOCOUNT ON
DECLARE crsrTransactions CURSOR LOCAL STATIC FOR
SELECT PolicyKeyID, Policy_Number, Portfolio_Set, Billed_Premium,
Billed_Fire_Fee, Pymt_Recvd, SC_Recvd,Trans_Type,Transcode,Type,Typec
ode
FROM Stage_Fire_Fee
ORDER BY Policy_Number, Policy_Date_Time ASC
OPEN crsrTransactions
FETCH NEXT FROM crsrTransactions INTO @.PolicyKeyID, @.Policy_Number,
@.Portfolio_Set, @.Billed_Premium, @.Billed_Fire_Fee, @.Pymt_Recvd,
@.SC_Recvd,@.Trans_Type,@.Transcode,@.Type,@.
Typecode
-- Outer Loop for all Transactions
WHILE @.@.FETCH_STATUS = 0
BEGIN
-- Initialize Running totals, reinitialize for each Policy #
SET @.Running_Premium = 0
SET @.Running_Fire_Fee = 0
SET @.Previous_Policy_Number = @.Policy_Number
IF @.Trans_Type IN
(@.NEW_BILL,@.RENEWAL,@.CANCELLATION,@.CHANG
E,@.RETURNED_CHECK,@.DISBURSEMENT,@.CAN
CEL_DISBURSEMENT,@.PYMT_REVERSAL)
-- Found basic Billed, so increment our running Premium and Fire Fee totals
BEGIN
SET @.Running_Premium = @.Running_Premium + @.Billed_Premium
SET @.Running_Fire_Fee = @.Running_Fire_Fee + @.Billed_Fire_Fee
END
ELSE IF @.Trans_Type = (@.PAYMENT)
-- Found Payment transaction, so subtract the paymnet from the total
amounts. Apply as much of the payment as possible to the Fire Fee Balance
BEGIN
SET @.Running_Premium = (@.Running_Fire_Fee + @.Running_Premium) -
@.Pymt_Recvd
IF @.Running_Fire_Fee <= @.Pymt_Recvd SET @.Running_Fire_Fee = 0
ELSE SET @.Running_Fire_Fee = @.Running_Fire_Fee - @.Pymt_Recvd
END
ELSE IF @.Trans_Type = (@.CASH_WITH_APP)
-- Found Payment transaction, so subtract the paymnet from the total
amounts. Apply as much of the payment as possible to the Fire Fee Balance
BEGIN
SET @.Running_Premium = (@.Running_Fire_Fee + @.Running_Premium) -
@.Pymt_Recvd
IF @.Running_Fire_Fee <= @.Pymt_Recvd SET @.Running_Fire_Fee = 0
ELSE SET @.Running_Fire_Fee = @.Running_Fire_Fee - @.Pymt_Recvd
END
ELSE
BEGIN
RAISERROR ('Unknown Transaction Type: %s', 0, 1, @.Trans_Type)
SET @.Error_Code_Tran = 1
SET @.Error_Code_Proc = 1
END
IF @.Error_Code_Tran = 0 UPDATE Stage_Fire_Fee SET Stage_Premium_Bal =
@.Running_Premium, Stage_Fire_Fee_Bal = @.Running_Fire_Fee WHERE PolicyKeyID =
@.PolicyKeyID
SET @.Previous_Policy_Number = @.Policy_Number
FETCH NEXT FROM crsrTransactions INTO @.PolicyKeyID, @.Policy_Number,
@.Portfolio_Set, @.Billed_Premium, @.Billed_Fire_Fee, @.Pymt_Recvd,
@.SC_Recvd,@.Trans_Type,@.Transcode,@.Type,@.
Typecode
SET @.Error_Code_Tran = 0
END
ENDOn Sun, 6 Nov 2005 16:44:36 -0800, Patrice wrote:

>Hi,
>I have the following procedure that I am trying to run on a data warehouse
-
>it is supposed to increase or decrease the running premium balance and the
>fire fee balance based on the type of transaction, but it seems to just be
>increasing the running balance - do you see where I am going wrong?
>Thanks in advance
Hi Patrice,
First some general advice:
1. Generally, don't store data that can be calculated in the database.
Each time the base data changes, you'll have to re-do all calculations.
Or you can choose to recalculate periodically, but then, the stored data
might be incorrect when you query the table.
2. Try to avoid cursors. They should only be used when all else fails,
or when you can prove that there is no reasonable set-based alternative.
On to your code.
It's hard to see what's going wrong, becuase you didn't include all
information needed to troubleshoot. Please post:
- The table structures, as CREATE TABLE statements (including all
constraints and properties, but excluding irrelevant columns),
- Some rows of sample data to illustrate the problem, as INSERT
statements,
- The expected output, and
- The output you are actually seeing.
Check out www.aspfaq.com/5006 for more suggestions on how to provide the
information we need in order to help you.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)