Re: Deployment + Vista

I'm talking about the user being able to edit the server connection setting
without manually editing XML.

Secondly my issue is with the SqlDataAdapters being hard bound to the
connection string which is an application setting. I'm aware that you can
change them to use a separate scheme and then have to call some method to
set the con string for you. This is an ommission on the part of the
framework and my question is does anyone know of a supported way at the
designer to redirect where this app string goes.

As for the manual way, if we do that where do you plan to put the server
config files? As I said you can't put them in the application directory, as
Vista will simply cache the change and throw it away when your program
exits, not persisting it (This is what I was trying to say in my last post).
I'm trying to allow the end user to change the settings in a dialog in an
easy way, and make our deployment much simpler eg First run of the
application spawns a dialog saying please enter dbase settings. You COULD
use the users directory, but then if you change which user you wish to
access the application, then you need to re enter obscure settings for an
end user, which should really already be there.

You certainly wont have a problem at deployment of a solution such as yours
especially with xcopy, but do you change the server config per MSI you
generate? or have a dialog in your msi (which is how we have done it as the
MSI will allow you to edit the app directory, even in Vista)

Any ideas?


"Earl" <brikshoe@xxxxxxxxxxxxxxxxx> wrote in message
news:%235DyoPMaHHA.5080@xxxxxxxxxxxxxxxxxxxxxxx
I'm guessing something didn't get cut and pasted into that reply, cuz you
lost me with the early part of your reply.

But interestingly enough, this past week I had to deploy an app onto a
small network. A few days later one of the offices had a new Vista
installation. Within a matter of minutes, I had XCopied the app and the
server.xml and server.xds files into a directory, fixed an unrelated
network connectivity issue (the server is on a different machine), and we
were off and running. Have had absolutely no problems with the Vista
machine at all in the scenario I described to you.

I'm not a big fan of using the app.config file to handle my server
settings. It's been a few years since I quit trying to use the app.config
file for that purpose, mainly because I wanted a more control over the
file and file structure that was being handled in order to save and
retrieve those settings.

I'm not sure how "Vista will temp your changes" because these are being
hard-written into the "server.xml" file (NOT the app.config file). Indeed
it seems to me that this is exactly the scenario where a file that
Microsoft does not control would be a better solution.

"Steven Spencer (Spinalogic)" <Spence-Spinalogic@xxxxxxxxxxxxxxxx> wrote
in message news:OlXlbZFaHHA.5080@xxxxxxxxxxxxxxxxxxxxxxx
Your description vista wise just fell over at "(into the app directory),
then give the user an input
panel so that they can specify any changes" Vista will temp your
changes to the app directory and then discard them upon exiting the
form.

Secondly:
Then I can call a GetConnectionString() function that calls the retrieval
function in order to put together the connection string something like:
m_strConnection = "data source=" + m_strSQLServerName + ";initial
catalog=" + m_strDatabaseName + ";integrated security=SSPI;"

I'm well aware of this pattern, and it is in fact the one I was using
previous to discovering the app.config setting.

My only problem with it is it is error prone for a multi developer
environment, if someone updates the data layer they may forget that call
and the app will look like it works fine in testing until we deploy...

I guess my question was exactly what I said: Is there a way at design
time to tell the sqldataadapters where to get its connection string from?
OR a way of using an application setting that is actually writeable at
runtime.


Either way, I do not wish to have to have to change the setting during
"Earl" <brikshoe@xxxxxxxxxxxxxxxxx> wrote in message
news:u0AtES6YHHA.1580@xxxxxxxxxxxxxxxxxxxxxxx
I know nothing about Vista, but you do not have to bind your connection
string to your strongly typed datasets.

In the display layer of the app, I keep the strongly-typed datasets
empty, then when I need data, I call .Merge() on the strongly typed
datasets in order to return datatables from the appropriate data layer
classes. Within those classes is where I open dynamically created
connections.

I deploy a small .xml and .xsd file with the default server name and
database settings (into the app directory), then give the user an input
panel so that they can specify any changes. Separately, I create a class
with separate functions to save and retrieve the settings, and with a
couple of properties for the server and database name. Then I can call a
GetConnectionString() function that calls the retrieval function in
order to put together the connection string something like:
m_strConnection = "data source=" + m_strSQLServerName + ";initial
catalog=" + m_strDatabaseName + ";integrated security=SSPI;"

As you can see, the only hard-coded aspect of the string is simply the
security. If necessary, you could even modify that, although if you are
deploying with SqlExpress, you already know what the security setting
will be.

"Steven Spencer (Spinalogic)" <Spence-Spinalogic@xxxxxxxxxxxxxxxx> wrote
in message news:eqTquLrYHHA.984@xxxxxxxxxxxxxxxxxxxxxxx
We use strongly typed datasets, and thus our connection string is bound
to an application setting.

Currently we can deploy and alter the app.exe.config file at
installation time to successfully install, and use some basic XML
editing to allow the target database to be changed.

Writing to the application directory in vista will throw compatibility
errors, and not persist the changes at all.

What do we do? Is there a better way of getting the connection string
in your application, or a way of telling the designer where to get your
connection setting from??









.

Relevant Pages

  • Complicated Connection Problems bewteen ADP and SQL Server
    ... This database ... expertise for getting the user workstations talking to the SQL Server. ... connection would fail and the adp wouldn't be able to talk to the server. ... might be in my ADO connection string. ...
    (microsoft.public.access.adp.sqlserver)
  • Complicated Connection Problem between ADP and SQL Server
    ... This database ... expertise for getting the user workstations talking to the SQL Server. ... connection would fail and the adp wouldn't be able to talk to the server. ... might be in my ADO connection string. ...
    (microsoft.public.sqlserver.connect)
  • Re: Complicated Connection Problems bewteen ADP and SQL Server
    ... front end on the 5-8 workstations where the users happen to sit. ... expertise for getting the user workstations talking to the SQL Server. ... connection would fail and the adp wouldn't be able to talk to the server. ... thought that I should instead change my connection string to something ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Digging in to trace files
    ... > Ed you are probably aware that even though the server is running MTS ... > you can create a dedicated connection when you need to correct? ... However, the app uses ... to shared server by requiring a high number of concurrent sessions ALSO ...
    (comp.databases.oracle.server)
  • Re: Deployment + Vista
    ... this past week I had to deploy an app onto a small ... I'm not a big fan of using the app.config file to handle my server settings. ... to the app directory and then discard them upon exiting the form. ... function in order to put together the connection string something like: ...
    (microsoft.public.dotnet.framework.adonet)