Yes - but that's what I understood the OP to be asking for.
I may have misunderstood.
S.
On 6/2/05, Michael Stover <[EMAIL PROTECTED]> wrote:
> I don't see how that's really going to help - it's still only going to
> be resolved once, and so only the first entry will be used for the whole
> test run.
>
> -Mike
>
> On Thu, 2005-06-02 at 18:59 +0100, sebb wrote:
> > I should have made clear that the CSVRead function calls have to be
> > entered on the thread group GUI in the appropriate field(s).
> >
> > Try it and see.
> >
> > S.
> > On 6/2/05, Michael Stover <[EMAIL PROTECTED]> wrote:
> > > The thread count in ThreadGroup is only going to work for static
> > > variables - ie, nothing that changes during a test run will work here.
> > > the reason is the variable is resolved at compile time, not runtime. If
> > > it doesn't have a value at that time, it will never be checked again.
> > >
> > > This means only jmeter properties and TestPlan variables will have an
> > > effect here. Just like listener filenames.
> > >
> > > -Mike
> > >
> > > On Thu, 2005-06-02 at 10:21 +0200, Sander Stevens wrote:
> > > > Hi Sebb,
> > > >
> > > > Sounds promising.
> > > > I did some testing, but without luck.
> > > > What I do is the following:
> > > >
> > > > In my user parameters I add one line with the variable name (rows) and
> > > > the __csvread to my csv file. The first column has the row count. So my
> > > > syntax is: ${__CSVRead(c:\temp\migration.csv,0)}
> > > > Secondly I use the variable in the Thread Group window.
> > > > Number of Threads: ${rows}
> > > > Ramp-up period: 50
> > > >
> > > > My script doesn't work anymore now. No result. Will stop directly.
> > > >
> > > > In the log I see the following:
> > > > 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Attaching
> > > > c:\temp\Migratie.csv
> > > > 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Opening
> > > > c:\temp\Migratie.csv as c:\temp\Migratie.csv
> > > > 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Saved
> > > > c:\temp\Migratie.csv as c:\temp\Migratie.csv delimiter=<;>
> > > > 2005/06/02 10:18:34 INFO - jmeter.functions.FileWrapper: Stored
> > > > c:\temp\Migratie.csv as c:\temp\Migratie.csv
> > > > 2005/06/02 10:18:34 INFO - jmeter.engine.StandardJMeterEngine: Starting
> > > > 0 threads for group ADSL. Ramp up = 50.
> > > >
> > > > The version of JMeter I am using is: 20050508 (internal version)
> > > >
> > > > Any ideas?
> > > >
> > > > Sander
> > > >
> > > > -----Original Message-----
> > > > From: sebb [mailto:[EMAIL PROTECTED]
> > > > Sent: donderdag 2 juni 2005 1:37
> > > > To: JMeter Users List
> > > > Subject: Re: Variable use in 'number of threads'?
> > > >
> > > > It's certainly possible to use a property to specify the number of
> > > > threads.
> > > > So functions work, i.e. CSVRead will work.
> > > >
> > > > The count should be placed in the first row of the CSV file.
> > > >
> > > > Try the following (tested):
> > > >
> > > > ${__CSVRead(test.txt,0)}${__CSVRead(test.txt,next)}
> > > >
> > > > Should also work for the ramp-up loop count if needed (not tested).
> > > > There is no guarantee that fields will be read in the same order in
> > > > each release, so all the values must be columns in the first row.
> > > > And you will either need to experiment to find which field should have
> > > > the "next" in it, or put it as the first entry in the UP
> > > > Pre-Processor.
> > > >
> > > > The rest of the file can then be read in a User Parameters (UP)
> > > > Pre-processor or in samplers etc.
> > > >
> > > > But it may be simpler to pass in the thread group settings as
> > > > properties, so you can use the same test file for different
> > > > variations, e.g.
> > > >
> > > > 1 thread, 10 loops
> > > > 2 threads 5 loops
> > > > etc
> > > >
> > > > S.
> > > > On 6/1/05, Sander Stevens <[EMAIL PROTECTED]> wrote:
> > > > > Hi,
> > > > >
> > > > > Maybe a nice idea (because I think it is not possible yet):
> > > > >
> > > > > I am using JMeter as a functional test tool with Excel (csv) as input
> > > > for my test cases. In this way I have to set the number of threads to
> > > > the number of rows in my excel sheet. No problem, but it would be nice
> > > > if this is filled automatically. Just to follow the excel sheet, even if
> > > > there are test cases (rows) added or deleted. The way I am thinking is
> > > > the following: I count the rows in the excel sheet (excel function
> > > > COUNT). Place the number of rows somewhere in the sheet, read this value
> > > > with function __CSVRead (e.g. rows) and use this value to notify the
> > > > number of threads (${rows}).
> > > > >
> > > > > Would that be a nice feature?
> > > > >
> > > > >
> > > > >
> > > > > Met Vriendelijke Groet,
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
