SalesLogix 7.5 Cannot Build Error

Today I got a call from one of my customers that could not build the new web client in the RC2 install of 7.5. The error that was occurring was due to the fact that some Attribute types could not be resolved. After looking at all of the usual suspects I decided to look at the Visual Studio build project that is created when the interfaces were being build. I also looked at a local project that I had here in the office.

Close inspection showed that the Sage.Platform reference path was different on the 2 machines. Mine was within the application directory where his was in a installed web client bin directory. This seemed strange to me, however I looked in the bin directory and noticed that the assembly dates were early 2008. Definitely an old version of the web client and would not have the functionality that was being referenced.

Note that this web client was installed in the Application Architect folder path as a sub directory. We moved the folder out of the Program File directory and then restarted AA and all compiled correctly. So it looks as if the process of generating the entity interfaces and compilation will have a difficult time if the web client is stored under the AA folders.

SalesLogix 7.5 RC2 Is Released

Yesterday night RC2 for SalesLogix was released out to the Business Partner community. The 7.5 release in my opinion represents the best release for the Web Client yet. I have to say I am getting excited that the product is getting ready for final release and SalesLogix customers will be able to get their hands on the product. It looks so much better then previous versions. The development team has been working hard and this is a great step forward.



Coding for Clarity

From time to time our clients ask us to look at software that was developed for them and assess its quality. This potentially leads to a refactor process where we might clean up code to reduce redundancies, make it more maintainable or to put it back on track to meet the end clients need. One of the observations that I have made and seems to resonate is with the way Adhoc SQL queries are written in code. I know that generally its not the greatest Idea in all cases and other solutions exist like stored procedures, ORM frameworks and the like but they are not always a viable solution to implement.

Back to my point.

Queries from what I notice are a concatenation of string parts and for the most part very difficult to easily understand because of this fragmentation. Core to the refactoring process is identifying the duplicate functionality and moving it into a shared component following a more DRY approach and increasing the overall maintainability of the project.

To this end I convert most of the adhoc sql statements to string.format( method calls that provide a string that looks as close to the requisite SQL as possible. That way through simpler inspection it is possible to see where the duplicate calls exist and identify proper patterns viable for a code refactor.


Write only enough code to do the job Right

Another thing that is really important is the KISS factor where doing only what is required for the current context is important. For example if you are using a constant value such as “T” do not call a format function as you are unnecessarily creating extra string objects and doing more work this is required. Set the value to “‘T’, ” if it is required and reduce the work.

Some Helper Functions can be Evil

We all write them, and use them extensively in our development, but helper functions need to be understood and applied in the most relevant places. For example a function that retrieves a single value from a database table can come in handy in a pinch. However, when the function needs to be called several times within a calling chain it is better to retrieve an object that is a composition of all of the needed values, reducing the round tripping to the database. For me one of the most evil functions that has come out of the SalesLogix scripting world and into the .net world is the get field call. This method makes it too easy go get values from the database and also too easy to write inefficient code.

Turning Off SuperFetch

SuperFetch is a service in Vista that caches applications to increase their startup performance. Great idea but for me seemed to be problematic. In previous posts I stated that I had purchased a new 8 GB computer. On this computer I do a lot of development, using VS, and VM products like VMWare and Microsoft Virtual PC. For the first time while compiling a SalesLogix Web client instance I had an out of memory error. Looking at my memory usage I had less then 10MB available. When I looked at my total/cache values the Cache was 5GB+. Given that I run some pretty memory heavy applications the cache seems to me at least that it does not play completely nice. Turning of the SuperFetch service seems to have put the computer in a better place.


Getting the 7.5 Web Client Working

For some time I have been having some difficulty setting up my Vista environment to get it working quite right. I had to do some testing this morning on some functionality and wanted to get into the client and create an adhoc group. previously I would get lockups and be able to do a short amount of work until my app pool would recycle. We I decided to associate my local logged in user to the app pool, and lo and behold all of my lockups were gone and the working on the site on the new machine screams ..


TheServerSide.Net, is it relevant?

I have a daily routine where I check blogs, and several web sites to  update my current understanding of .Net development. One of the sites that I frequent is TheServerSide.Net. The problem for me now is that it seems that it has become stale. For example today looking at the site the last post was on August 8th, 5 days ago. What is strange is that SP1 for VS 2008  released and not even a single post up about it. Going to the sister site TheServerSite.COM the content is updated so much more frequently.

The hardware shift cometh

As a development company I had been looking for commodity hardware that could meet the daily write/build/deploy needs that I have. I finally found a machine that could readily be purchased from a local electronics retailer and what seemed a amazing price. 8 GB of Ram, Quad 4 64 Bit machine for 1500 bucks. Well I was out last night and stopped in to the same retailer where another computer was on the shelf with comparable specs except for the fact that it had an AMD CPU instead of Intel. This machine was listed for $1299.

I have also been reading that the growth rate for 64 bit Vista is outpacing all others at this time. For me it finally looks as if 64 bit is a legitimate  platform to target windows applications and now is the time to make sure that any existing applications play well.

– Mark