1) Add a registry value to exceed the 1000 record limit
Create a registry key HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 11.0\Crystal Reports\DatabaseOptions\LOV
Then add a string value “MaxRowsetRecords” and set the value to the maximum number of records you would like for your report.

(Counts all parameters..not just each level)

2) Add a dynamic filter w/ ‘…All” as an additional item.

You can set up a command to do this.

In your Database expert there is the Add Command option just above your DB source.

Double click the Add command and put the following code

SELECT FIELD (your vendor field that you want to select from here) FROM table (the table your vendor field is in) UNION SELECT ‘…All’

Now in your dynamic parameter, reference this Command item instead of field In your Selection Formula use your standard Parameter references

A quick example would be the total number of Cases related to a particular record.

count($cases,"amount")

From the SugarCRM Developer Blog HOWTO: Use Sugar Logic Rollups.

I resolved the issue by commenting the following 5 lines in include/logging.php:

if (! isset($simple_log) || $simple_log == false) {
$config = new LoggerPropertyConfigurator();
$config->configure('log4php.properties');
}

From what I can tell, the issue is partly SugarCRM bug in 5.2.0 and/or 5.5.1, and also caused by the outdated version of the Zucker Reports module installed on the system. westphal noted his system had ZuckerReports as well as other modules that used similar methods for interacting with the SugarCRM Logging tools.

It’s worth noting that attempting to simply uninstall Zucker won’t solve the problem, because Module Loader will fail due to the same Logger references that trip up Repair & Rebuild.

After applying westphal’s fix, removing Zucker, and a Repair & Rebuild, the system was stable at 5.5.1 and I was able to continue my upgrade.

Logic hooks are well enough explained in the Developer Guide and other sites like Angel Magaña’s Simple SugarCRM Logic Hook Example. I won’t explain them in-depth here. What I want to get into is detecting changes on key fields. That said, here’s an example of a logic hook that does just that:

<?php
class DataSync{
	/*
	 * The method that does the checking for the specific fields. This is
	 * the method that we'll want to call in the logic_hooks.php file.
	 */
	function CheckUpdatedFields($bean, $event, $arguments){
		// if there are more than one field you're interested in, use an array
		$key_fields = array('phone_home','phone_other','phone_work');
		// and cycle through them
		foreach($key_fields as $key_field){
			// do a change detection leveraging the fetched_row value
			if($bean->$key_field != $bean->fetched_row[$key_field]{
				// and if a change is detected, queue up the Sync method
				$this->SyncToSystem($bean,$key_field);
			}
		}
	}

	/*
	 * A Generic Placeholder function, to be called when a change is detected
	 */
	function SyncToSystem($bean,$field){
		// placeholder
		return true;
	}
}

This hook is doing the change-detection by leveraging the $bean->fetched_row value. fetched_row holds the information from the database that was originally retrieved. This works in a before_save logic hook, because the database value hasn’t yet been updated, but the $bean->$field itself has been changed. Comparing the live value ($bean->$field) and the stored database value (in $bean->fetched_row[$field]) will show whether or not that field has been modified.

LinkedIn Discussion (note that you must be logged in to LinkedIn and join the Sage Saleslogix group to read and participate).

What was happening during Configuring the Spotfire Server for Sage SalesLogix?

In this step one sets up:

Authentication Tab

Data Source Templates tab

User Directory Tab

Impersonation Tab

Login Behavior tab

All of these set up values are pretty easy except for the Authentication Tab.  This requires typing the connection string.

The name pair value consists  of :  

• custom.db.connection
• jdbc:jtds:sqlserver://<database server>:<port>/<Sage SalesLogix Database name>

This should be fairly simple

jdbc:jtds:sqlserver://SQLServername/SQLInstance:1433/SalesLogixEval

In turns out that the jdbc connection does NOT recognize the SQLInstance name.  The perils of using SQLExpress with a SQL Instance.

jdbc:jtds:sqlserver://SQLServername:1433/SalesLogixEval

Choose Advanced Settings

Change the Enable 32 Bit from False to True

When I need it, I copy the file from an old module and paste it into my current directory. I adjust the description, name (PSI for Profiling Solutions, and the year-month-dayofmonth), published date* and id (same as the name). Install defs is set to copy everything from the package’s custom/ directory into the SugarCRM custom directory, overwriting whatever is there along the way.

It’s quick and clean, ideal for ongoing projects. I’ll have several packages kept in the SugarCRM root directory of the project, each directory and modularized ZIP named the same as $manifest ['name'] for quick identification.

<?php
$manifest = array (
	'acceptable_sugar_versions' => array (),
	'acceptable_sugar_flavors' => array(),
	'readme'=>'',
	'key'=>'PSI',
	'author' => 'Profiling Solutions, Inc.',
	'description' => 'adjust quote-to-opp conversion and updates',
	'icon' => '',
	'is_uninstallable' => true,
	'name' => 'PSI_20120120',
	'published_date' => '2012-01-20 10:05:57',
	'type' => 'module',
	'version' => '1.0',
);
$installdefs = array(
	'id' => 'PSI_20120120',
	'copy' => array (
		array (
			'from' => '<basepath>/custom',
			'to' => 'custom',
		),
	),
);

* Full disclosure: Sometimes I only adjust the date part of published_date, and don’t even touch the time portion! We rarely upload more than one package in a day so I get away with it. Scroll back to the top.

In current versions of SugarCRM, information about custom fields on stock modules is scattered in several places. In the process of creating a new text-input field for Accounts called “Certifications,” we would find that the following would take place

• a file created at /custom/Extension/modules/Accounts/Ext/Vardefs/sugarfield_certifications_c.php that held some, but not all, of the advanced vardef information (e.g. SugarLogic)
• after the repair-and-rebuild of the system (which Studio will automatically call), the data from the above file is compiled (with other custom Vardefs, if they are present) into /custom/modules/Accounts/Ext/Vardefs/vardefs.ext.php.
• the file at /custom/modules/Accounts/language/en_us.lang.php was created or modified with the language data for the Certification field
• the database table accounts_cstm was created or modified to include a certifications_c field.
• data was inserted into the the database table fields_meta_data containing the vardef data for the field.

However, suppose we created the vardef file ourselves? And the language file? We can actually author the entire vardef, specifying field names (ever wanted to drop the _c suffix? Maybe for some address fields?). By doing so, we get the entire thing under our preferred VCS. It’s as straight-forward as creating the full field definition array in the first file location. The dificulty for some will come in the database. When you attempt your repair-and-rebuild, SugarCRM will find a vardef that isn’t defined in metadata, and so will incorrectly assume that the field should be appended to the default table (i.e. accounts instead of accounts_cstm). While this works, it’s less upgrade-safe than using the _cstm table.

Let’s go start-to-finish for our Certifications field.

Create the file /custom/Extension/modules/Accounts/Ext/Vardefs/sugarfield_certifications_c.php with the following contents:

<?php
$dictionary['Account']['fields']['certification_c'] = array(
    'name' => 'certification_c',
    'vname' => 'LBL_CERTIFICATION_C',
    'type' => 'varchar',
    'len' => '255',
    'audited'=>false,
    'required'=>false,
    'comment' => 'List Certification'
);

This definition is pretty bare-bones, but that’s because we’re using a text field. If you used an enum (dropdown) field type, then you’d be sure to specify the options parameter, and there are several more parameters involving reporting and searching. For a better understanding of the parameters for a particular field type or function, the trick is to find an existing field of the type or function in the system and track down it’s vardefs, usually somewhere like /modules/Accounts/vardefs.php.

That handles the vardefs, so let’s do the same for the relevant language strings. Studio places the language strings it creates in /custom/modules/Accounts/language/en_us.lang.php, but repair-rebuild will do something similar function. Let’s stick with our top-level Extension directory. Create the file /custom/Extension/modules/Accounts/Ext/Language/en_us.certifications_c.php (be sure you have your en_us or language-specific prefix) with the following line:

<?php
$mod_strings['LBL_CERTIFICATION_C'] = 'Certifications';

The field and it’s label are defined in the system, but before we run our repair-and-rebuild to activate it, we need to set up the database. We’ll a SQL statement to add the data to fields_meta_data.

INSERT INTO fields_meta_data (id,name,vname,comments,custom_module,type,len,required,deleted,audited,massupdate,duplicate_merge,reportable,importable) VALUES ('Accountscertification_c','certification_c','LBL_CERTIFICATION_C','List Certification','Accounts','varchar',255,0,0,0,0,0,1,0);

Like the vardef itself, this query varies depending on field type. The fields match pretty closely to the vardef itself so you should be able to decipher basic fields.

Now that we have everything defined in the system, similarly but more-so to what Studio would generate for us, we can run repair-and-rebuild. RaR will notice that the actual field hasn’t been set up on accounts_cstm yet, and so will prompt you to do so (providing the query).

/*Checking Custom Fields for module : Accounts */
CREATE TABLE accounts_cstm ( id_c char(36) NOT NULL, PRIMARY KEY ( id_c ) ) CHARACTER SET utf8 COLLATE utf8_general_ci;
/*MISSING IN DATABASE - certification_c -  ROW*/
alter table accounts_cstm add column certification_c varchar(255)  NULL ;

If you already have custom fields for Accounts, the CREATE statement won’t show up, only the ALTER statement. Once you execute the statement, you’ll be informed that

Your field will then be accessible for use, and you can add it to your views via Studio or via code as normal.

A Note About the Future

SugarCRM announced in a recent community webinar that an goal for the system will be to do away with fields_meta_data and ensure that more aspects of the system are being controlled through code, instead of the current hybrid setup. At that point, there will be one less step in this process.