Suggestions..

Brian Donahue

Hi Gary,

My name is Brian Donahue, and I support Red Gate Software. Thanks for
your enquiries:

> Allow the Database passwords to be remembered when connecting to a
database.
Then they would have to be stored somewhere, like in the registry. I don't
think most people would be comfortable with that. Using integrated security
might be your best bet, anyway.

> Do not default the option for the top database when scripting.
The plan is to add a USE command at the top of the script, so the script
will run on the correct database. That's the simplest way to avoid any
confusion.

> Always keep the databases in the same order (Alphabetic??).
I know what you mean here. I put this on our 'to-do' list about two
weeks ago. Unfortunately nobody had time to look at it before version 2.03
came out, but may appear in the future.

> I guess I don't see why it is two separate programs.
Maybe they're better on their own, like shampoo and conditioner, or
detergent and fabric softener. ;-)

> Thanks for the great software! It's a life saver.
Thanks for trying Red Gate Software. Tell your friends!

Brian Donahue

Technical Support Engineer

Red Gate Software Ltd.

T: +44 870 1600 037

E: mailto:brian.donahue@red-gate.com


"Gary Chamberlain" <Gary@nospam.com> wrote in message
news:kjoD$QDsCHA.1348@server53...
>
> Allow the Database passwords to be remembered when connecting to a
database.
> I understand that this is a security issue. However, many people are like
> me. A small local shop with secure PCs. It's a pain to keep going off to
> get the password (very strong so I never remember it) and entering it. It
> would be nice if this were configurable so that the user could define if
DB
> passwords are remembered.
>
> Do not default the option for the top database when scripting. It is way
to
> easy to forget and take the script for the wrong database. Since you
really
> have no way of knowing which database we are updating, you shouldn't
> default. Require the user to select the correct database before showing
any
> script.
>
> Always keep the databases in the same order (Alphabetic??). It is
annoying
> and somewhat dangerous that they move around. For example, select the top
> database and then click the refresh toolbar button. It is now on the
> bottom.
>
> What would be really nice is a full move that both updates the database
> schema and makes an exact copy of the data. I suppose this is a marriage
> between the SQL Compare and SQL Data Compare apps. I guess I don't see
why
> it is two separate programs.
>
> Thanks for the great software! It's a life saver.
>
> Gary Chamberlain
>
>

Brian Donahue

Hi,

Good point. Actually, I've made a suggestion already, that SQL Compare
and Data Compare be able to use data sources that are already set up on the
user's computer, which would also alleviate the effort of having to type in
a user/password all of the time. Does that sound like a more 'elegant'
solution?


"Eric Smith" <idontneedanyspam.eric.smith@e-hht.com> wrote in message
news:hKBPRvD2CHA.1444@server53...
>
> *Certainly* RedGate could get the option of saving the password or not to
> the user. A company should never select policy for it's users with it's
> application.
>
> Eric Smtih
>
> "Dave Hall" <dhall@deboy.com> wrote in message
> news:AnSqKjeuCHA.2304@server53...
> > Just wanted to echo Gary's suggestions and cast one more vote for giving
> the
> > user the option to "remember passwords". The security issue is then up
to
> > the user, but in environments where it's not an issue, the tool becomes
> > easier to use.
> >
> > Another feature that would be helpful in addition to the multi-selection
> > that has been requested several times already, is the ability to select
> > based on pattern matching object names.
> >
> > Another thing that I'd like to see is the ability to compare objects
which
> > have the same name, but differ only in the owner. A common problem I
> > encounter is that an object is inadvertantly scripted without specifying
> an
> > owner, then the script is run on two databases while connected as
> different
> > users, then the object is identical except for the owner. Subsequently,
> > someone alters the object on one database, still specifying the owner,
and
> > the two objects are now different, and I can't use the tool to compare
> them.
> > Here's an example:
> >
> > create view V_WithoutOwnerSpecified
> > as select Id, Name from SomeTable
> >
> > Now I login to the Development database with integrated security and
> create
> > the view. It defaults to dbo as the owner, and the fully quaified view
is
> > named dbo.V_WithoutOwnerSpecified. I then have a customer run the script
> on
> > the Customer database, but they're logged in with SQL security as
AppUser,
> > so we end up with a view called AppUser.V_WithoutOwnerSpecified. The
> problem
> > is that I can't easily compare the two views to determine if they are
the
> > same or not because the owner is different.
> >
> > Thanks for a great product. Looking forward to more and better...
> >
> > Thanks,
> > Dave
> >
> >
>
>

Brian Donahue

SQL Compare 3.x now remembers the previous SQL authentication settings and stores the username and password as encrypted BLOBS in the user profile portion of the registry.