Manage parameter dropdown list

I have an input parameter which has multi-value property checked. It has
dependence on the other input parameter and its value set is getting from
database. So, the number of row change when the other parameter changes. The
problem is the dropdown list sometime works fine, but the other time it
doesn't work as expected. For instance, there is case that there are only
two values in the list and the dropdown list gives me "Select All", first
item and a scroll bar. I need to drag the scroll bar to see the second item.
This is very annoying. The only good thing is that it did work consistently
in the sense of same value set always has same look in the dropdown list.
Is there a way to manage the displayable size of the dropdown list? How
about the input parameter text box length, is there anyway we can have any
control over this?Hi,
As you have mentioned that the "select ALL" comes as the first option and
you need to scroll down for the other two options. I think your query (in the
dataset) for this parameter is having spaces. Just have a look at the query
again and try to eliminate the null / space in your dataset.
Amarnath
"lu" wrote:
> I have an input parameter which has multi-value property checked. It has
> dependence on the other input parameter and its value set is getting from
> database. So, the number of row change when the other parameter changes. The
> problem is the dropdown list sometime works fine, but the other time it
> doesn't work as expected. For instance, there is case that there are only
> two values in the list and the dropdown list gives me "Select All", first
> item and a scroll bar. I need to drag the scroll bar to see the second item.
> This is very annoying. The only good thing is that it did work consistently
> in the sense of same value set always has same look in the dropdown list.
> Is there a way to manage the displayable size of the dropdown list? How
> about the input parameter text box length, is there anyway we can have any
> control over this?
>|||Sorry, if I didn't make it clear. No, what I said was the dropdown list
display first two items which are "Select All" and the first item in the
value set when I have only two items in the value set. Why I need to use
scroll bar to be able to see the second item. The dropdown list should just
have a window big enough to accomodate all three choice which are "Select
All", first item and second item.
"Amarnath" wrote:
> Hi,
> As you have mentioned that the "select ALL" comes as the first option and
> you need to scroll down for the other two options. I think your query (in the
> dataset) for this parameter is having spaces. Just have a look at the query
> again and try to eliminate the null / space in your dataset.
> Amarnath
> "lu" wrote:
> > I have an input parameter which has multi-value property checked. It has
> > dependence on the other input parameter and its value set is getting from
> > database. So, the number of row change when the other parameter changes. The
> > problem is the dropdown list sometime works fine, but the other time it
> > doesn't work as expected. For instance, there is case that there are only
> > two values in the list and the dropdown list gives me "Select All", first
> > item and a scroll bar. I need to drag the scroll bar to see the second item.
> > This is very annoying. The only good thing is that it did work consistently
> > in the sense of same value set always has same look in the dropdown list.
> > Is there a way to manage the displayable size of the dropdown list? How
> > about the input parameter text box length, is there anyway we can have any
> > control over this?
> >
> >sql

Maintenance required after deploying merge pull replication?

Hi,
Before I ask for input, I just want to thank everyone in this
newsgroup for being so helpful... I've really gotten through some
complicated issues thanks to the information here. People like Hilary
are always coming through.
I am deploying a solution that depends on Continuous Merge Pull
replication... I can configure the systems of my customers, but once I
deploy them, I won't have direct administrative access to their copy
of MSDE which contains a pull subscription to our central database.
If needed, I could write an application to interface with MSDE through
the ActiveX controls...
What sort of control am I going to need so that I can always be sure
they are in sync? How can I make sure that if the connection is
dropped, or a new article is added, that they automatically keep
retrying until the process works?
In general, what are the problems do you think I might have after
deploying this sort of solution? Is it even workable without being
able to remote administer?
Thanks again
josh
Josh,
the agent failure/retry/success alerts should take care of some of these
concerns, provided you can configure email integration in your MSDEs.
To ensure the data is correctly transferred, occasional validation could be
used.
To ensure that the merge agent keeps retrying in the event of a network
failure, you can force it to work in an infinite loop (step 3 of the merge
agent's job step can have 'on success' and 'on failure' going back to step
2).
HTH,
Paul Ibison
|||So with an infinite loop trying to sync, will I also be covered for
any of the issues that normally cause the agent to stop?
For instance, replicating schema changes and new articles typically
requires a new snapshot, so the merge agent just stops itself (even in
continuous mode) until an up-to-date snapshot is posted. Will the
loop allow it to keep checking this?
Basically, I have no administrative access over the MSDE once it is
deployed (since it is on dynamic IP), and need to be sure there is
nothing that can cause sync to fail.
I suppose if the MSDE is on dynamic IP, there is no good way to
configure after deployment. Perhaps using replication is not the best
choice in this scenario. ..
Any input appreciated.
Thanks again,
josh
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message news:<eTsOlvAYEHA.3476@.tk2msftngp13.phx.gbl>...
> Josh,
> the agent failure/retry/success alerts should take care of some of these
> concerns, provided you can configure email integration in your MSDEs.
> To ensure the data is correctly transferred, occasional validation could be
> used.
> To ensure that the merge agent keeps retrying in the event of a network
> failure, you can force it to work in an infinite loop (step 3 of the merge
> agent's job step can have 'on success' and 'on failure' going back to step
> 2).
> HTH,
> Paul Ibison
|||Josh,
the loop will protect against network issues but not adding new articles.
When the article is added, you'll need to run the snapshot agent
immediately, to ensure the merge agent doesn't stop. You could have a step
in the snapshot agent (sp_start_job) which restarts the merge agent if
necessary.
Not to sure about the dynamic IP bit. The Netbios name is normally used
rather than the IP address to connect using Enterprise Manager. If you are
replicating to a subscriber on a non-trusted domain or over the internet
then I could see your problem.
The thought that you could no longer monitor the subscriber makes me
concerned, and in my opinion this will be a problem as time goes by. Perhaps
you could have the subscriber run a job on a schedule which posts its IP
address to the publisher, so you have the option of troubleshoting if
necessary.
Regards,
Paul Ibison

Maintenance Plan tips

Hi!
I'm trying to set up a new Maintenance Plan for a new MS SQL Server 2005.
And would like
some input on my backup plan.
Background
The server is a database development server where databases are added and
deleted on a weekly basis. All the newly added databases has to be backuped
without any need for backup configuration changes.
In case of a crash/mistake I would like the most recent backup to be no
older
than 24h, as well as you have to be able to go one week back in time to
restore a database.
How does the below backup plan look?
Full backups on saturdays
Differential backups sunday - friday.
All backups kept for 2 weeks
Is this a good plan or is there a better way.
pros/cons?
/FredrikThis is a multi-part message in MIME format.
--090500030204080306040605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Fredrik Danielsson wrote:
> Hi!
> I'm trying to set up a new Maintenance Plan for a new MS SQL Server 2005.
> And would like
> some input on my backup plan.
> Background
> The server is a database development server where databases are added and
> deleted on a weekly basis. All the newly added databases has to be backuped
> without any need for backup configuration changes.
> In case of a crash/mistake I would like the most recent backup to be no
> older
> than 24h, as well as you have to be able to go one week back in time to
> restore a database.
> How does the below backup plan look?
> Full backups on saturdays
> Differential backups sunday - friday.
> All backups kept for 2 weeks
> Is this a good plan or is there a better way.
> pros/cons?
> /Fredrik
>
>
Hi Frederik
Is there any reason why you will run differential backups? Unless the
database are really big, I'd simply just do a full backup every night.
That makes administration easier and when you have to restore a backup,
it's only a single file you need to restore.
Regards
Steen Schlüter Persson
Databaseadministrator / Systemadministrator
--090500030204080306040605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Fredrik Danielsson wrote:
<blockquote cite="mideyPuwE3mGHA.4960@.TK2MSFTNGP04.phx.gbl" type="cite">
<pre wrap="">Hi!
I'm trying to set up a new Maintenance Plan for a new MS SQL Server 2005.
And would like
some input on my backup plan.
Background
The server is a database development server where databases are added and
deleted on a weekly basis. All the newly added databases has to be backuped
without any need for backup configuration changes.
In case of a crash/mistake I would like the most recent backup to be no
older
than 24h, as well as you have to be able to go one week back in time to
restore a database.
How does the below backup plan look?
Full backups on saturdays
Differential backups sunday - friday.
All backups kept for 2 weeks
Is this a good plan or is there a better way.
pros/cons?
/Fredrik
</pre>
</blockquote>
<font size="-1"><font face="Arial">Hi Frederik<br>
<br>
Is there any reason why you will run differential backups? Unless the
database are really big, I'd simply just do a full backup every night.
That makes administration easier and when you have to restore a backup,
it's only a single file you need to restore.<br>
<br>
<br>
-- <br>
Regards<br>
Steen Schlüter Persson<br>
Databaseadministrator / Systemadministrator<br>
</font></font>
</body>
</html>
--090500030204080306040605--|||Fredrik Danielsson wrote:
> Hi!
> I'm trying to set up a new Maintenance Plan for a new MS SQL Server 2005.
> And would like
> some input on my backup plan.
> Background
> The server is a database development server where databases are added and
> deleted on a weekly basis. All the newly added databases has to be backuped
> without any need for backup configuration changes.
> In case of a crash/mistake I would like the most recent backup to be no
> older
> than 24h, as well as you have to be able to go one week back in time to
> restore a database.
> How does the below backup plan look?
> Full backups on saturdays
> Differential backups sunday - friday.
> All backups kept for 2 weeks
> Is this a good plan or is there a better way.
> pros/cons?
> /Fredrik
>
Have a look at the script I've posted here: http://www.realsqlguy.com/?p=8
I'm not a big fan of maintenance plans, I think they hide certain
critical operations from the "administrator", when that person really
should understand what's going on.
The script I've linked to is used on my production servers (slightly
edited for public consumption). The script is scheduled to run every
five minutes, and each time it runs, it does the following, for each
database on the server:
- if a database is in Simple recovery mode, and it has been 24 hours
since the last full backup, a full backup is done
- if it is has been more than 7 days since a full backup was done of a
database, a full backup is done
- if it has been more than 3 days since a full backup, and it's
currently after 9:00pm on Friday, a full backup is run. This keeps your
full backups clustered around the weekends, typically non-production
time in many environments.
- if a database is in Simple recovery mode, and the log is 75% full, the
log is truncated
- if a database is not in Simple mode, and the log is 75% full OR it has
been more than 5 minutes since the last t-log backup, a transaction log
backup is done
Sounds like this would be perfect for your environment. The script will
automatically detect new databases as they are added. You shouldn't
have to touch a thing.|||Fredrik Danielsson wrote:
Hi!
I'm trying to set up a new Maintenance Plan for a new MS SQL Server 2005.
And would like
some input on my backup plan.
Background
The server is a database development server where databases are added and
deleted on a weekly basis. All the newly added databases has to be backuped
without any need for backup configuration changes.
In case of a crash/mistake I would like the most recent backup to be no
older
than 24h, as well as you have to be able to go one week back in time to
restore a database.
How does the below backup plan look?
Full backups on saturdays
Differential backups sunday - friday.
All backups kept for 2 weeks
Is this a good plan or is there a better way.
pros/cons?
/Fredrik
Hi Frederik
Is there any reason why you will run differential backups? Unless the
database are really big, I'd simply just do a full backup every night. That
makes administration easier and when you have to restore a backup, it's only
a single file you need to restore.
Regards
Steen Schlüter Persson
Databaseadministrator / Systemadministrator
Hi Steen,
The reason why I'm thinking about doing Differential backups is because
there are a number of large databases that we receive from our customers.
These databases are only used to migrate data from, they are never altered.
It would be enterly possible to do full backups every night on the
development databases. But the databases that we receive can be quite large.
(30-40GB)
The machine only has 270 GB of space for databases and backups.
If there is a simple way of excluding some databases from the backups there
would be no problem. But it's more important that new databases are included
in the backups
/Fredrik|||Fredrik D wrote:
> Fredrik Danielsson wrote:
FYI, SQL backup compress REALLY well. You might consider creating a
compressed OS volume on which to store your backup files.|||Microsoft Compression is not supported on and SQL Server files (data,
log, backup, or otherwise). See this link:
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
You are better off using SQLBackup or LiteSpeed if you need to compress
your backups.
Tracy McKibben wrote:
> Fredrik D wrote:
> > Fredrik Danielsson wrote:
> FYI, SQL backup compress REALLY well. You might consider creating a
> compressed OS volume on which to store your backup files.|||PSPDBA wrote:
> Microsoft Compression is not supported on and SQL Server files (data,
> log, backup, or otherwise). See this link:
> http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
>
Interesting, because I've been compressing my backup folders for YEARS.
You are absolutely correct that the data and log files cannot be
compressed, but the BACKUPS can be. From the article you linked to,
under the Compression heading:
"All SQL Server database log and data files should remain in an
uncompressed state."
Not a word about backups...
> You are better off using SQLBackup or LiteSpeed if you need to compress
> your backups.
Why? If you want to do real-time compression without using the OS
compression, pipe the backup through GZip. Does EXACTLY the same thing
that either of those products do, with a much lower price tag.|||Fredrik D wrote:
Hi Frederik
By using a Maintenance Plan, there're no way to "automate" wgich
database are being backed up. Instead you can script you backup jobs and
then in some way here select which databases you want to backup. That
will require that you in some way "mark" which databases you need to
backup and which you don't. That can be e.g. by naming. You could maybe
also look for a create date or something like that, but I don't know how
safe that will be.
On one of my servers, I'm using a script that back up all database that
starts with a certain string. This server is a Cognos BI database server
and all the applications/databases that are created by the users are
named with e.g. 'pl_xxxxxx'. The script then just backup all databases
where the name starts with "pl_xxxx". By doing this, I don't have to
worry about any new databases that are being created without my knowledge.
Regards
Steen Schlüter Persson
Databaseadministrator / Systemadministrator|||Tracy, please read:
http://support.microsoft.com/default.aspx?scid=kb;en-us;231347
Tracy McKibben wrote:
> PSPDBA wrote:
> > Microsoft Compression is not supported on and SQL Server files (data,
> > log, backup, or otherwise). See this link:
> > http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
> >
> Interesting, because I've been compressing my backup folders for YEARS.
> You are absolutely correct that the data and log files cannot be
> compressed, but the BACKUPS can be. From the article you linked to,
> under the Compression heading:
> "All SQL Server database log and data files should remain in an
> uncompressed state."
> Not a word about backups...
> > You are better off using SQLBackup or LiteSpeed if you need to compress
> > your backups.
> Why? If you want to do real-time compression without using the OS
> compression, pipe the backup through GZip. Does EXACTLY the same thing
> that either of those products do, with a much lower price tag.