Configuration failing: The path is not of a legal form.

When I push Add in the configuration dialog, I cannot even get to the first page of the configuration wizard, due to the following error, in several solutions (but not in several others). All have at least one existing configuration (necessarily, to get passwords for connections).
**
An error occurred while a new configuration was being added.
Additional Information:
The path is not of a legal form. (mscorlib)

**

PS: How have the rest of you been posting? Passport hasn't been working much this week, so I've been unable to post. Is there a way to post without using passport? Please tell me if so :)

What types of configuration (XML configuration file, Environment variable, etc) do your packages use?|||This is a known issue when you edit the package "standalone",
i.e. without creating the SSIS project. A workaround is to create
the project, add the package to the project, and then edit
the configuration.

We plan to fix this issue for SP1 (it was reported too late to
consider changing this for RTM release).

Thanks,
Michael.|||(Sorry, I have to wade through a lot of script errors and bad passport certificate errors to be able to post to this forum.)
The configuration involved is an environment variable pointing at an XML config file.
The package is in a project in a solution.
However, the solution has two packages, one of which calls the other.
Because of the bug that Execute SSIS task cannot handle relative paths, we have to use a mapped drive to call the package, so the target package is called via a mapped drive fully qualified file path.
I've since discovered that the bug here is that if the package is opened from the mapped drive, even though it is the same file, the Package Configuration Wizard will give this mscorlib error. The workaround for this bug is to be careful and be sure to first close the package, then open it by double-clicking it in the solution, when you need to examine or edit package configurations.
Of course, I hope this bug gets fixed, but truly, it is not nearly as bad as the bug that relative paths get wrecked and fail in the Execute SSIS task.
|||I see - this indeed seems like a different bug.
Could you please open a bug on betaplace?|||re: bug on betaplace
I invested some time trying to get into betaplace, which involved waving my cursor around to find an invisible button I had to click, and then getting to a page which said I would be granted access at some point. I tried several times on successive days, but I never got further than that. I posted my travails several times to the newsgroup, but noone had any suggestions, so I finally gave it up as something that only costs me time, and brought no benefit to anyone (as I was never able to get to a point of actually accessing any information, much less posting new bugs).
Could you open the bug on betaplace? I have a suspicion that it probably works much better for people working at Microsoft :)

|||OK, I'll open a bug directly in our bug tracking system.|||Hi,
I know its probably to late for you ( Perry_Rapp )
but for other who trying to find solution to the "The path is not of a legal form" problem here it is:

1. open a new project/solution
2. copy the old project\s to the new "solution folder"
3. add the old project\s to the new solution from the new "solution folder".
(right click on "solution" -> Add -> Existing Project... )

Note:
if you have virtual folders in your solution first add the old project\s to the new solution root and after saving .. create the virtual folders

Configuration failing: The path is not of a legal form.

When I push Add in the configuration dialog, I cannot even get to the first page of the configuration wizard, due to the following error, in several solutions (but not in several others). All have at least one existing configuration (necessarily, to get passwords for connections).
**
An error occurred while a new configuration was being added.
Additional Information:
The path is not of a legal form. (mscorlib)

**

PS: How have the rest of you been posting? Passport hasn't been working much this week, so I've been unable to post. Is there a way to post without using passport? Please tell me if so :)

What types of configuration (XML configuration file, Environment variable, etc) do your packages use?|||This is a known issue when you edit the package "standalone",
i.e. without creating the SSIS project. A workaround is to create
the project, add the package to the project, and then edit
the configuration.

We plan to fix this issue for SP1 (it was reported too late to
consider changing this for RTM release).

Thanks,
Michael.|||(Sorry, I have to wade through a lot of script errors and bad passport certificate errors to be able to post to this forum.)
The configuration involved is an environment variable pointing at an XML config file.
The package is in a project in a solution.
However, the solution has two packages, one of which calls the other.
Because of the bug that Execute SSIS task cannot handle relative paths, we have to use a mapped drive to call the package, so the target package is called via a mapped drive fully qualified file path.
I've since discovered that the bug here is that if the package is opened from the mapped drive, even though it is the same file, the Package Configuration Wizard will give this mscorlib error. The workaround for this bug is to be careful and be sure to first close the package, then open it by double-clicking it in the solution, when you need to examine or edit package configurations.
Of course, I hope this bug gets fixed, but truly, it is not nearly as bad as the bug that relative paths get wrecked and fail in the Execute SSIS task.
|||I see - this indeed seems like a different bug.
Could you please open a bug on betaplace?|||re: bug on betaplace
I invested some time trying to get into betaplace, which involved waving my cursor around to find an invisible button I had to click, and then getting to a page which said I would be granted access at some point. I tried several times on successive days, but I never got further than that. I posted my travails several times to the newsgroup, but noone had any suggestions, so I finally gave it up as something that only costs me time, and brought no benefit to anyone (as I was never able to get to a point of actually accessing any information, much less posting new bugs).
Could you open the bug on betaplace? I have a suspicion that it probably works much better for people working at Microsoft :)

|||OK, I'll open a bug directly in our bug tracking system.|||Hi,
I know its probably to late for you ( Perry_Rapp )
but for other who trying to find solution to the "The path is not of a legal form" problem here it is:

1. open a new project/solution
2. copy the old project\s to the new "solution folder"
3. add the old project\s to the new solution from the new "solution folder".
(right click on "solution" -> Add -> Existing Project... )

Note:
if you have virtual folders in your solution first add the old project\s to the new solution root and after saving .. create the virtual folders

Configuration failing: The path is not of a legal form.

When I push Add in the configuration dialog, I cannot even get to the first page of the configuration wizard, due to the following error, in several solutions (but not in several others). All have at least one existing configuration (necessarily, to get passwords for connections).
**
An error occurred while a new configuration was being added.
Additional Information:
The path is not of a legal form. (mscorlib)

**

PS: How have the rest of you been posting? Passport hasn't been working much this week, so I've been unable to post. Is there a way to post without using passport? Please tell me if so :)
What types of configuration (XML configuration file, Environment variable, etc) do your packages use?|||This is a known issue when you edit the package "standalone",
i.e. without creating the SSIS project. A workaround is to create
the project, add the package to the project, and then edit
the configuration.

We plan to fix this issue for SP1 (it was reported too late to
consider changing this for RTM release).

Thanks,
Michael.|||(Sorry, I have to wade through a lot of script errors and bad passport certificate errors to be able to post to this forum.)
The configuration involved is an environment variable pointing at an XML config file.
The package is in a project in a solution.
However, the solution has two packages, one of which calls the other.
Because of the bug that Execute SSIS task cannot handle relative paths, we have to use a mapped drive to call the package, so the target package is called via a mapped drive fully qualified file path.
I've since discovered that the bug here is that if the package is opened from the mapped drive, even though it is the same file, the Package Configuration Wizard will give this mscorlib error. The workaround for this bug is to be careful and be sure to first close the package, then open it by double-clicking it in the solution, when you need to examine or edit package configurations.
Of course, I hope this bug gets fixed, but truly, it is not nearly as bad as the bug that relative paths get wrecked and fail in the Execute SSIS task.
|||I see - this indeed seems like a different bug.
Could you please open a bug on betaplace?|||re: bug on betaplace
I invested some time trying to get into betaplace, which involved waving my cursor around to find an invisible button I had to click, and then getting to a page which said I would be granted access at some point. I tried several times on successive days, but I never got further than that. I posted my travails several times to the newsgroup, but noone had any suggestions, so I finally gave it up as something that only costs me time, and brought no benefit to anyone (as I was never able to get to a point of actually accessing any information, much less posting new bugs).
Could you open the bug on betaplace? I have a suspicion that it probably works much better for people working at Microsoft :)
|||OK, I'll open a bug directly in our bug tracking system.|||Hi,
I know its probably to late for you (

Perry_Rapp )
but for other who trying to find solution to the "The path is not of a legal form" problem here it is:

1. open a new project/solution
2. copy the old project\s to the new "solution folder"
3. add the old project\s to the new solution from the new "solution folder".
(right click on "solution" -> Add -> Existing Project... )

Note:
if you have virtual folders in your solution first add the old project\s to the new solution root and after saving .. create the virtual folders
sqlsql

concurrent access during snapshot generation

We are using SQL 2K with sp4 and a push transaction subscription.
In the Publication properties, under the snapshot tab, there is a check box
for 'Concurrent access during snapshot gneration', the default is not
checked.
1. I am thinking about checking the box because the benefit is great, but
what is the consequence? I am curious of why it isn't default to 'checked' box
2. If leaving it unchecked, say I have 100 tables in the snapshot, the
system only locks a table one at a time during the process, they shouldn't
lock all the tables at once, am I right?
wingman
For the first part, the methodology is different. Transactions made during
the snapshot time are sent to the distribution database and will be
synchronised after the snapshot. This is possible in transactional because
it is transaction-based, but not in merge. However, in some cases it might
be desirable to quiesce the articles while they are being snapshotted, so as
to limit the transactions getting queued up. I'm not too sure if your
assumption is correct about the second part and will check it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
Thanks for the explanation. Just so I understand it correctly because I
don't quite know the word 'quiesce' means.
If the box is unchecked, the snaplock process will stop any transactions
being sent to the distribution database until the snapshot is done.
If the box is checked, any transactions will be sent to distribution
database, which in turns sends them to the subscriber database while snapshot
is going on.
Your answer prompts me a new question or a clarification of what I thought I
understand. When that check box indicates "Do Not lock tables during
snapshot generation.....'. What does it mean? Does it lock the tables in
publisher database or in subscriber database?
"Paul Ibison" wrote:

> For the first part, the methodology is different. Transactions made during
> the snapshot time are sent to the distribution database and will be
> synchronised after the snapshot. This is possible in transactional because
> it is transaction-based, but not in merge. However, in some cases it might
> be desirable to quiesce the articles while they are being snapshotted, so as
> to limit the transactions getting queued up. I'm not too sure if your
> assumption is correct about the second part and will check it.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Wingman,
it's referring to a table-lock on the publisher. The tables usually don't
exist on the subscriber, or if they do, the default is to drop them anyway.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
Sorry I am still not quite clear. Please pattern me and clarify the following
So if I unchecked the box(tables will be locked), when the snapshot is
happening, which of the following scenario is happening:
1. the snapshot process will stop any transactions being sent to the
distribution database until the snapshot is done. This means any changes to
any tables are sitting in the queue of the distribution database. During the
snapshot process, the tables involved are locked.
2. the snapshot process will only stop transactions related to the tables
involved in the snapshot and these transactions will be held in the queue of
the distribution database. This means changes are still allowed to be made
to other tables except the tables involved in the snapshot. During the
snapshot process, the tables involved are locked.
If the box is checked, are the above situations reversed? For example,
there will be no queueing in the distribution database and the tables
involved in the snapshot are not locked.
Again, thank for your time and patience very much.
"Paul Ibison" wrote:

> Wingman,
> it's referring to a table-lock on the publisher. The tables usually don't
> exist on the subscriber, or if they do, the default is to drop them anyway.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||With the box unchecked, it is the tables on the Publisher that are locked.
Other processes trying to update these tables will be blocked until the lock
is removed. This should be verifiable by testing and simultaneously
profiling or using the current activity window.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)