Tuesday, May 17, 2005

Problems with Word after installing PD 11

In case anybody else has run into this, this is from a newsgroup posting from "Seth S." about how to overcome issues with Word after PD11 is installed. The problem is that Word loads the PowerDesigner plug-in by default (everytime you use Word), not just when PowerDesigner needs it. For me it's been a real issue because I use Word as the editor for Outlook, so it keeps getting loaded when I'm in Outlook as well.

One minor correction. That key shows up for me under HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE as the newsgroup post indicated.


The workaround is to change the LoadBehavior of the DLL in Word


LoadBehavior should be set to '3' and you must set it to '2'. After that Ms Word will not load the DLL anymore.

NOTE: The add-in remains listed in the Global Template and Add-in box and the contextual menu named 'requirements' is still on the menu. These things will be address in the cr 376227.


Monday, May 02, 2005

Must have improvements for the next version of PowerBuilder

A while back I took the new features I had suggested in my PBDJ editorial from last year, all the input from last TechWave's enhancement section discussion and all of the suggestions from a long thread a while back in the future_directions forum and I entered them into the ISUG enhancement request system.

Sunday, May 01, 2005

Dynamically creating an Access database

Even need to export data in an Access database format? It may be a little easier than you think, or even the way you're currently doing it.

Two things to consider:

1. You can dynamically create a Access database file without having Access on the system.
2. You can connect to that database and write data to it without ever creating ODBC entries for it.

The first item is possible because the Microsoft Data Access Components, which are installed as part of the operating system on most recent Microsoft operating systems, allow you to perform a number of database operations through OLE Automation. The actually implemention looks something like this:

oleobject l_adocatalog
string ls_database = "c:asaexport.mdb"

l_adocatalog = CREATE oleobject
l_adocatalog.ConnectToNewObject ( "ADOX.Catalog" )
l_adocatalog.Create ( "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + ls_database )
Destroy l_adocatalog

Of course, you would add some appropriate error checking and wrap most of the calls in a try/catch block to allow gracefully recovery from any OLE Automation errors.

The second item is accomplished through something called a "DNSless Connection". That is, rather than create an ODBC entry and point to that in the ODBC ConnectString, we simply give the ODBC drivers everything they need to get connected directly in the ConnectString. In the case of Access, all we need to do it tell it the Driver we want to use and where the file is located in the DBQ paramater, as well as the uid and pwd we would use for any typical ODBC ConnectString:

SQLCA.DBParm = "ConnectString='Driver={Microsoft Access Driver (*.mdb)};Dbq=" + ls_database + ";Uid=admin;Pwd='"

I've put this all together in a little sample app on CodeXchange that creates an Access data file dynamically and the pipelines data from the ASA sample database to that new Access data file.