Whidbey: Add New data source does not work.

[Guest]

My computer was moved last week, and the company changed the network groups
we work on. As a result, one of the main benefits from Whidbey (database
connectivity) no longer works.
Situation:
1. I open a new project based on a windows form
2. I click on "data" and then "Add New Data Source" then I click on next
within the wizard
3. I have 3 choices Database, Local Database, Web service and Object.
4. I choose Database, click next and get the following error message:
--------------------------------------
An unexpected error has occurred.
Error Message: Key not valid for use in specified state
Call Stack: at
Microsoft.VisualStudio.Data.DataProtection.DecryptString(String s)
at
Microsoft.VSDesigner.VSDesignerPackage.ConnectionServiceHelper.AddServerExplorerConnections(IServiceProvider serviceProvider, IList connections)
at
Microsoft.VSDesigner.VSDesignerPackage.GlobalConnectionService.Microsoft.VSDesigner.VSDesignerPackage.IGlobal
ConnectionService.GetConnections(IServiceProvider serviceProvider)
at Microsoft.VSDesigner.Data.VS.DbSourceWizardUtil.GetGlobalConnections
(IServiceProvider serviceProvider)
at
Microsoft.VSDesigner.Data.DataSourceWizard.Database.DbConnectionPage.InitializeConnections()
at
Microsoft.VSDesigner.Data.DataSourceWizard.Database.DbConnectionPage.OnEnterPage(EventArgs e)
at Microsoft.VSWizards.WizardPage.RaiseEnterPage()
at Microsoft.VSWizards.WizardForm.NextPage()
at Microsoft.VSWizards.WizardForm.Next_Click(Object sender, EventArgs e)
-----------------------------------------------------
Does any one have any idea why this happens?
My preface was put in because I had no trouble with Whidbey before the move,
and I use the database connectivity extensively.

Lastly, the Local Database choice seems to work, but really doesnt. While
the Wizard works, the resulting dataset cannot retrieve (Load for preview)
data from the database, and the programs using it don't seem to be able to
update the database.

I'd be very happy if you could help.
rogsonl

 

[Gerry O'Brien [MVP]]

First off, be careful what you post in the public groups regarding Whidbey.
Ensure that your topics are not still under NDA prior to posting.

Verify that you don't have any datasource configuration information in the
app.config file. Remember that Whidbey can save that information from
previous datasource configurations.

Do you have SQL installed by any chance on your local machine? If so,
ensure that you can connect to the required data source remotely using
Enterprise Manager.

Remember that the Local Database option is for MDB or MDF files that are
stored locally on the dev machine and not across the network.


ps, that dialog gives you 4 choices, not 3 ;-)

 

[Guest]

Thank you for the information.
I should be classified as "clueless" concerning Whidbey. I did not realize I
was under an NDA, and assumed that we were in an area under MSDN, and
therefore that most of us had access to Whidbey. The forum was suggested to
me by Microsoft when I sought to enlist them to help me resolve my problem.
It stops my development using Whidbey cold.

The database in question is an Access database, not an SQL database. I do
have an SQL database locally as well, but am not using it at the moment.

The app.config file which fails (and works at home) is as follows:
=========================================
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.diagnostics>
<sources>
<!-- This section defines the logging configuration for
My.Application.Log in Windows Forms projects.-->
<source name="Microsoft.VisualBasic.MyServices.Log.WindowsFormsSource"
switchName="DefaultSwitch">
<listeners>
<add name="FileLog" />
<!-- Uncomment the below section to write to the Application Event
Log -->
<!--<add name="EventLog"/>-->
</listeners>
</source>
</sources>
<switches>
<add name="DefaultSwitch" value="Information" />
</switches>
<sharedListeners>
<add name="FileLog" type="System.Diagnostics.FileLogTraceListener,
Microsoft.VisualBasic, Version=8.0.1200.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
initializeData="FileLogWriter" />
<!-- Uncomment the below section and replace APPLICATION_NAME with the
name of your application to write to the Application Event Log -->
<!--<add name="EventLog"
type="System.Diagnostics.EventLogTraceListener"
initializeData="APPLICATION_NAME"/> -->
</sharedListeners>
</system.diagnostics>
<connectionStrings>
<add name="Person2.MySettings.Connection"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=D:\Work\JonesTony\Bookmarks.mdb;Persist Security Info=False"
providerName="System.Data.OleDb" />
<add name="Person2.MySettings.Connection1"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=.\Bookmarks.mdb;Persist Security Info=True"
providerName="System.Data.OleDb" />
</connectionStrings>
</configuration>
=========================================
This could not be the problem, however, since the problem happens when I
open a new solution and project, and I would assume the app file would look
as follows:
==============
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<sources>
<!-- This section defines the logging configuration for
My.Application.Log in Windows Forms projects.-->
<source
name="Microsoft.VisualBasic.MyServices.Log.WindowsFormsSource"
switchName="DefaultSwitch">
<listeners>
<add name="FileLog"/>
<!-- Uncomment the below section to write to the
Application Event Log -->
<!--<add name="EventLog"/>-->
</listeners>
</source>
</sources>
<switches>
<add name="DefaultSwitch" value="Information" />
</switches>
<sharedListeners>
<add name="FileLog"
type="System.Diagnostics.FileLogTraceListener,
Microsoft.VisualBasic, Version=8.0.1200.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
initializeData="FileLogWriter"/>
<!-- Uncomment the below section and replace APPLICATION_NAME
with the name of your application to write to the Application Event Log -->
<!--<add name="EventLog"
type="System.Diagnostics.EventLogTraceListener"
initializeData="APPLICATION_NAME"/> -->
</sharedListeners>
</system.diagnostics>
</configuration>
=====================================
This config file does not mention any database.
Thanks for your suggestion.
Leon
PS. Let me know what to do about Whidbey, and where to get the info not to
infringe in any NDA.

 

[Gerry O'Brien [MVP]]

I guess I should have been a little more cautious in making that statement
as well because it depends on how and where you got Whidbey. If you have
acquired but have not signed nor seen and NDA, then you are obviously not
bound by an NDA.

If it is a public beta, then by all means discuss until the cows come home.
Or at least for the next milking. ;-)

As for the data source connection, yes it does get stored in the app.config
file if you choose to save that information when you create the data source.

As to why you cannot get a new connection, that is strange without any
entries in the app.config.

What build of Whidbey are you using?

 

[Guest]

Here is the version information:
================================
Microsoft Visual Studio 2005 Beta 1
Version 8.0.40607 .16 (beta 1 .040607 -1600 )
2004 Microsoft Corporation . All rights reserved.
Microsoft .NET Framework
Version 2.0.40607
2004 Microsoft Corporation . All rights reserved.
================================
I believe the problem arouse when my computer was moved and at the same time
my association changed from an old obsolete company unit, to a new one (my
company was bought out and this is part of our merge).

Whidbey still works properly on a separate machine.

When I uninstalled Whidbey, I could not get the macros in the .net
environment (version 1.1) to work. After a lot of discussion with Microsoft,
they suggested I reformat my hard disk!
Thank God, I was on a server so I used my local admin entry to eliminate my
login, rather than reformat my entire disk. I also found a config.net2 file
(I am not sure about the name) which after I deleted it while local, resolved
the problem and allows me to use .net version 1.1.

I have learned my lesson. Never load a beta product!
Thanks for your help and interest
Leon

 

[Gerry O'Brien [MVP]]

Oh that's always fun. Beta products on a production machine. OUCH!

Actually, my employer is doing it on his laptop and desktop and so far has
experienced no issues.

I prefer to use Virtual PC and the soon to be release Virtual Server to host
beta software on. That way, no serious issues arise.

At any rate, I don't think I helped much but I'm glad to you are some sort
of working solution.


--
Gerry O'Brien [MVP]
Visual Basic .NET(VB.NET)