"XPpro SP2" blocking the Application Server in Dreamweaver MX 2004 !?!

[IndigoDragon]

Hi there,

I'm encountering the following problem that some of you must have encountered...

After setting up my new workstation with "XP Pro SP2" and installing "Dreamweaver MX 2004" I found out that there's a problem with the database connectivity. Setting up a connectionstring works just fine; Dreamweaver tells me that the connection has been made succesfully. However, when selecting a connection, no tables can be retrieved from the connection. Also, with my existing connections, in the Application-Databases panel, no tables are shown (to be precise, it says "none").

So I looked around on Macromedia's site and found the following article:

http://www.macromedia.com/cfusion/k...1a&stateID=0+0+24015957&mode=simple#aspnet_db

This article recognizes the problem and tells me to install the extension "Windows SP2 DB Connectivity Fix" that should fix the problem. Well, you've guessed: the problem still persists after installing the extension!

Has anyone encountered this before and does anyone have a sollution for this?

Thanx for your replies!!!

IndigoDragon

 

[madanthrax]

Yes, I had a similar problem on my network. DW suddenly stopped showing DB table contents in the right GUI pane. I use Notepad mainly for developing but the three web content editors use DW for updating the html/asp pages.

It seemed to come after a MS security update about 3 weeks before Xmas, not sure which one. It affected DW GUI connections to our SQL 2000 Database, but the pages worked still on the servers. I believe it must have affected the DNS resolution somehow. OurDB page connections use aliases such as RSwebDB for the server which is really called Q5. When I changed the connection string to use the real servername Q5 DW immediately started working again.

Sorry I have no conclusive help for you. I use Q5 in the connection string on the dev server and the alias on the live server. Maybe this will help you find a solution.

Ant

_{"Nothing is impossible until proven otherwise"}​

 

[madanthrax]

Correction:

When I wrote MS security update, I meant on the SQL server probably.

_{"Nothing is impossible until proven otherwise"}​

 

[IndigoDragon]

Hey Madanthrax,

thanx for your answer!

Yep, it's definately after that security update, I've confirmed that asking 'round on the web. So, there's probably not much to expect from MS... the sollution's gonna have to come from us...
Your 'workaround' seems like a longshot, also 'cos I'm stuck with the SP's path.
However, I've heard about a sollution that you might be able to help me with:
Set up a System DSN on the local machine referring to the ftp root folder of the publication server. This seems to 'trick' XP into accepting the connection. Sounds simple enough to try out but I've not been able to set up the ODBC connection. How do I set up the connection? I think I have to give up the path in the "network" section of the "ODBC Microsoft Access Setup" window. Select "no drive" and give up the path to the server. Now that's where I'm snagged. It doesnt't accept any formats I've put in... What would be a correct path-format to a remote ftp-server? I've tried "\\domain\rootfolder\", "ftp://domain/rootfolder", etc.

Any suggestions?
Thanx!

 

[madanthrax]

Problem is I work in an Enterprise environment. The system DSNs I setup are to Data sources (such as SQL). I have found if you do not get a connection to the database then the DSN doesn't save. If you are trying to use a FTP path for a data source it ain't gonna work. I haven't used MS Access in the last seven years so I don't think I can be of much help there.

Although the idea of tricking XP is appealing, what about this security update? Have you tried to pin it down and deinstall it, this would be the simplest solution. Hell, unistall them one by one around the time frame in question and see which one is to blame, then live without it. I had to do the same on my laptop which runs IIS5 when an update stopped asp pages running. Trouble is on a PC everyone is used to taking auto updates from MS, the server guys here are much more selective about what updates are really necessary and read up and test them before deploying them so as not to affect functionality.

Your other option is to go to the SQL or Access forums for help.

_{"Nothing is impossible until proven otherwise"}​