Source Control object definition comparisons

Is there a way to apply code formatting both to the object definitions (table, views, etc.) fetched from the database and to the corresponding workspace files before comparing them?

Unfortunately there is none. It compares the code pulling database objects code as is. However, you can do a batch export of database objects to some work-folder, apply batch formatting using the sacmd, and then compare the entire folder against files in the workspace.

Just in case, here is a copy and paste from the on-line user's guide

Using DOS Batch Processing to Format Multiple SQL Files

The following example demonstrates how to use standard DOS commands in a batch file to recursively invoke SQL Assistant's command line interface and reformat multiple SQL Files:
1. Save the following text as format_sql_files.bat file in any folder on your system:

	Code:
	@ECHO OFF SET curr_dir=%CD% CD "C:\Program Files\SQL Assistant" FOR %%f IN (%1\*.sql) DO ( ECHO Processing file %%~ff SACMD fmt:"%%~ff" sas:"%APPDATA%\SQL Assistant\6.0\sqlassist.sas" fpref:%2 > NUL ) CD "%curr_dir%" ECHO Done

2. Copy all SQL files that you want to reformat to folder C:\SQL Scripts.
3. Open command prompt, navigate to the folder where you saved format_sql_files.bat file, and execute the following command:

	Code:
	format_sql_files.bat "C:\SQL Scripts" "T-SQL Default Style"

Note: The above batch script example has been tested on Windows XP system. Changes might be required before running it on other versions of Windows systems. In the script above please verify and if necessary correct SQL Assistant installation path.

Well, this could be useful, and I'm planning to integrate something similar into my file manager for ages, but this does not really solve my problem. Actually, views, procedures and functions are not affected because their definition is probably already stored formatted. The situation is different when retrieving the CREATE clause for a table. These are generated by the DDL query and that code is not formatted, hence the saved workspace/repository file won't be either. Editing it is much easier when it's formatted so this is how it is eventually going to be saved and committed to the repository. Committing the changes to the database will probably (I haven't tried yet) drop and recreate the table (and all its fripperies like indices, triggers, constraint, etc.) but retrieving it CREATE clause will necessarily differ from the one saved in workspace/repository, which is already formatted and this will mark the file modified. Being able to optionally pre-format both the retrieved code and workspace/repository code prior the comparison could address this issue.