did you check the fielddefinitions? using ESS there's an option for resynch/reconnect the tables or something like that.
The developer that manages the SQL part is making himself very unavailable for assistance on this. He seems to think that going VM is a very bad idea.
The VM is not a factor here; so disregard the SQL guy's remarks on that. Most enterprise deployments these days are all VM and all work fine.
The DSN test works fine when you set it up?
The VM server will have a different LAN IP address are you sure the SQL has this IP address permitted in its remote connection. If it also has a different WAN IP address and is connecting over the WAN that needs to be added as well
Just something to check
"The VM is not a factor here; so disregard the SQL guy's remarks on that. "
Yes, I know. Just explaining why I'm not just asking the guy that set this up to fix it.
Both machines are on the same LAN, but some kind of "white list" of permitted IP addresses is something that has also occurred to me. That may cause my boss to bring up the "big guns" to compel some cooperation here.
Wim's question took me back into the dialog for setting up the DSN. I hadn't seen any way to test the connection so when I went looking for it, I discovered, to my chagrin, that I'd not paid attention to the fact that there were additional steps to setting up and completing the DSN creation process. Once I filled in a user name and password (since these are also specified in the external data source definitions, I didn't realize that I needed to set them up here as well) and got to a dialog to test it, the test worked and when I opened up the solution, the shadow tables were showing the data that they should instead of "0 records".
Thanks all and time to go wipe a little egg off my face after making such a "newbie" mistake.