Tracker

Fix Your Access Database

Stuart Radcliffe — Fri, 24 Mar 2006 10:27:00 GMT

Fix Your Access Database
This page tells you about an automated web service that will help you retrieve data and software from a corrupt or damaged Access database for a fee (Minimum US$50).

Problems with ActiveX Controls in Microsoft Access

Stuart Radcliffe — Sat, 19 Feb 2005 19:58:00 GMT

Microsoft has recently been on a security kick. This has become the number one priority. Sometimes the decisions that are made in implementing security fixes are just not thought through and result in the breaking of existing solutions. I came across one such instance today.

Stephen and some of my other colleagues were doing a server install at one of our clients. This involved the introduction of a new server running Windows 2000 SP4 Terminal Services. The server is used to run the front end of the main database application for the client. The front end runs on Access 2003 and is accessed through Terminal Services.

One of the features of this application is an image displaying form that uses the Kodak (formerly Wang) Image Edit Control to display the images. When trying to use the application this form was giving an error and when I tried to re-insert the control I got a message saying that the control was not compatible with Access. I knew this to be untrue as I can happily open up the form and use the control using the computer I am typing this on.

So, after some Googling, I came across a couple of references to the problem. This one implied a possible solution. The related Microsoft article was next to useless but the page that I found it from offered a solution (actually for the Rich Text ActiveX control but it worked none the less).

The problem appears to be that Microsoft have introduced a new security feature aimed at stopping certain ActiveX controls from running in Internet Explorer. This is in the form of some registry entries that define the compatibility of these controls. The Kodak Imaging controls are marked as not compatible and indeed there shouldn't really be any need to use them in Internet Explorer. Unfortunately, for some reason, Microsoft Access looks at the same registry entries and determines that the controls should not be compatible in Access either. This just doesn't make any sense. There can be many occasions when what is a security risk when viewing web pages in a browser simply is not any kind of a risk when used in a controlled application in an Access database. Stupid decision.

Anyway, the appropriate registry keys are as follows:

Kodak Image Admin Control - HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{009541A0-3B81-101C-92F3-040224009C02}
Kodak Image Edit Control - HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{6D940280-9F11-11CE-83FD-02608C3EC08A}
Kodak Image Scan Control - HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{84926CA0-2941-101C-816F-0E6013114B7F}
Rich Text Control - HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{3B7C8860-D78F-101B-B9B5-04021C009402}

Within the registry key for the appropriate control there will be an entry for Compatibility Flags that will be set to 0x400 (hexadecimal 400, decimal 1024) if the control is disabled. To enable it, change this value to 0.

Access Magic Numbers

Stuart Radcliffe — Thu, 10 Feb 2005 16:58:00 GMT

There are a number of problems that can occur when working with the colours of Microsoft Access form and report controls. The Microsoft developers included some "magic numbers" that can be used to set a colour to match some other value. e.g. Set the control's BackColor property to -2147483633, and it will always be the same as the BackColor property setting for the detail section on the form. More details are available at http://ewbi.blogs.com/develops/2004/12/access_magic_co.html

Microsoft Moving Away from ADPs in Access

Stuart Radcliffe — Fri, 06 Aug 2004 08:01:00 GMT

Kent Tegels quotes Mary Chipman (who wrote the book) in the SSXE newsgroup as saying that Microsoft are now recommending moving away from ADP based solutions. It looks like this may be an experiment that has not been completely successful which leaves those of us who have implemented these solutions with an interesting support problem going forward. Here is the quote:

However, for new application development, ADPs aren't looking so promising, especially if you are thinking in the Yukon timeframe. A couple of problematical issues are complex data types and CLR assemblies. Tackling these head-on in the ADP UI graphical tools in the next version of Access is a daunting challenge, to say the least.

...and...

FWIW, the Access team has moved away from recommending ADPs as a front-end to SQLS apps over the last year or so, based on several public talks given by team members at industry conferences. If you are contemplating new development with Access as a FE to a SQLS BE, you'll likely be ahead of the game with an efficiently-designed MDB/linked table solution rather than an ADP.

Connection String Generator

Stuart Radcliffe — Thu, 22 Jul 2004 14:53:00 GMT

Useful when you can't quite remember that setting...

http://ambroise.neve.be/library/content/oledb.asp

UPDATE:

Lots more info here.

Tip - Joint Agents Fees in Tracker

Stuart — Fri, 14 May 2004 11:30:00 GMT

If you have a joint agents fee in Tracker then, by default, the full amount will still be against the relevant surveyor on the fees report. To change this, you can go into the Fee Summary form for the appropriate fee and click on the Split Fee button. You can then add a new line with Other in the Surveyor column and Joint Agency in the Profit Centre column. You should make sure that you have a Surveyor record with Other and a Profit Centre for Joint Agency beforehand. Now, when you do your fees reports, the fee will be apportioned in the appropriate manner.