Обсуждение: pgAgent "new step" fails for batch jobs in pgAdmin3 1.10.0 Beta 2
If you pick Batch rather than SQL for "Kind", you naturally can't edit the database or connection string, but the SQL generated has commas and blanks (i.e., nothing, not even an empty string) for those columns, and so fails: INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc, jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr) SELECT <StpId>, 5, E'C:\\mybat.bat', '', true, 'b', 'f', E'C:\ \mybat.bat', , ; With those options selected it should either put nulls or get rid of the commas and the ", jstdname, jstconnstr", right?
> INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc, > jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr) > SELECT <StpId>, 5, E'C:\\mybat.bat', '', true, 'b', 'f', E'C:\ > \mybat.bat', , ; Also that <StpId> is a problem if you try to copy this out and run the query manually, which I had to do because when I unchecked "read only" and edited it to get rid of the last two parameters, I got the same error message about commas, leading me to think that what I saw on the screen was not what actually got sent to the db server by pgAdmin (so I'm not sure what the benefit is to being able to edit it there, if you have to open a query window to actually execute your edited version anyway.) But when I took out "jstid, " and "<StpId>, " in addition, it worked. Forgot to mention, I'm on win32.
On Mon, May 4, 2009 at 6:25 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: > If you pick Batch rather than SQL for "Kind", you naturally can't edit > the database or connection string, but the SQL generated has commas > and blanks (i.e., nothing, not even an empty string) for those > columns, and so fails: > > INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc, > jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr) > SELECT <StpId>, 5, E'C:\\mybat.bat', '', true, 'b', 'f', E'C:\ > \mybat.bat', , ; > > With those options selected it should either put nulls or get rid of > the commas and the ", jstdname, jstconnstr", right? That was fixed here: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=7800&view=rev It'll be in beta 2. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, May 4, 2009 at 6:31 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: >> INSERT INTO pgagent.pga_jobstep (jstid, jstjobid, jstname, jstdesc, >> jstenabled, jstkind, jstonerror, jstcode, jstdbname, jstconnstr) >> SELECT <StpId>, 5, E'C:\\mybat.bat', '', true, 'b', 'f', E'C:\ >> \mybat.bat', , ; > > Also that <StpId> is a problem if you try to copy this out and run the > query manually, which I had to do because when I unchecked "read only" > and edited it to get rid of the last two parameters, I got the same > error message about commas, leading me to think that what I saw on the > screen was not what actually got sent to the db server by pgAdmin (so > I'm not sure what the benefit is to being able to edit it there, if > you have to open a query window to actually execute your edited > version anyway.) But when I took out "jstid, " and "<StpId>, " in > addition, it worked. It's because creating jobs needs to be a multi-step process so it puts a placeholder in the SQL which will be replaced at execution time with the result from another part of the process. It's still potentially useful to edit the definition before sending it to the server, but I agree it's not something you can run standalone. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On May 5, 8:20 am, dp...@pgadmin.org (Dave Page) wrote: > On Mon, May 4, 2009 at 6:31 PM, Kevin Field <kevinjamesfi...@gmail.com> wrote: > > query manually, which I had to do because when I unchecked "read only" > > and edited it to get rid of the last two parameters, I got the same > > error message about commas, leading me to think that what I saw on the > > screen was not what actually got sent to the db server by pgAdmin (so > > I'm not sure what the benefit is to being able to edit it there, if > > you have to open a query window to actually execute your edited > > version anyway.) But when I took out "jstid, " and "<StpId>, " in > > the result from another part of the process. It's still potentially > useful to edit the definition before sending it to the server, but I > agree it's not something you can run standalone. About editing, I just tried this in the win32 beta3, and it still ignores the changes you make: I went to create a new job step, selected batch, typed gibberish in the name and definition, unchecked 'read only', and erased the generated SQL and replaced it with "select 'hello'", and then clicked OK, and it added the gibberish step (rather than doing nothing, which is what select-hello should've done...) So 'read only' doesn't seem to be useful at this point. Thanks for pointing out the other fix though, that seems to work. :) Kev
On Mon, May 11, 2009 at 3:43 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: > > About editing, I just tried this in the win32 beta3, and it still > ignores the changes you make: I went to create a new job step, > selected batch, typed gibberish in the name and definition, unchecked > 'read only', and erased the generated SQL and replaced it with "select > 'hello'", and then clicked OK, and it added the gibberish step (rather > than doing nothing, which is what select-hello should've done...) So > 'read only' doesn't seem to be useful at this point. Oh, I see what you mean. If memory serves, the pgAgent dialogues process their SQL in a slightly different way to all the other dialogues because they need to run some parts in different steps. Guillaume; this is your code ( :-p ) - do you see a simple way to fix it, or should the checkboxes be disabled on the three pgAgent dialogues? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page a écrit : > On Mon, May 11, 2009 at 3:43 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: >> About editing, I just tried this in the win32 beta3, and it still >> ignores the changes you make: I went to create a new job step, >> selected batch, typed gibberish in the name and definition, unchecked >> 'read only', and erased the generated SQL and replaced it with "select >> 'hello'", and then clicked OK, and it added the gibberish step (rather >> than doing nothing, which is what select-hello should've done...) So >> 'read only' doesn't seem to be useful at this point. > > Oh, I see what you mean. If memory serves, the pgAgent dialogues > process their SQL in a slightly different way to all the other > dialogues because they need to run some parts in different steps. > > Guillaume; this is your code ( :-p ) - do you see a simple way to fix > it, or should the checkboxes be disabled on the three pgAgent > dialogues? > Actually, it's not really useful in that context. We should simply disable the checkbox on these dialogs. Perhaps we don't even need an SQL tab? Regards. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Mon, Jun 8, 2009 at 10:23 PM, Guillaume Lelarge<guillaume@lelarge.info> wrote: > Dave Page a écrit : >> On Mon, May 11, 2009 at 3:43 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: >>> About editing, I just tried this in the win32 beta3, and it still >>> ignores the changes you make: I went to create a new job step, >>> selected batch, typed gibberish in the name and definition, unchecked >>> 'read only', and erased the generated SQL and replaced it with "select >>> 'hello'", and then clicked OK, and it added the gibberish step (rather >>> than doing nothing, which is what select-hello should've done...) So >>> 'read only' doesn't seem to be useful at this point. >> >> Oh, I see what you mean. If memory serves, the pgAgent dialogues >> process their SQL in a slightly different way to all the other >> dialogues because they need to run some parts in different steps. >> >> Guillaume; this is your code ( :-p ) - do you see a simple way to fix >> it, or should the checkboxes be disabled on the three pgAgent >> dialogues? >> > > Actually, it's not really useful in that context. We should simply > disable the checkbox on these dialogs. Perhaps we don't even need an SQL > tab? I think it's still useful to display the SQL, if only to allow the user to see what pgAdmin is going to do. Disabling (better yet, removing) the checkbox on those dialogues seems like the right answer. Can you do that in the next day or so? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page a écrit : > On Mon, Jun 8, 2009 at 10:23 PM, Guillaume > Lelarge<guillaume@lelarge.info> wrote: >> Dave Page a écrit : >>> On Mon, May 11, 2009 at 3:43 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: >>>> About editing, I just tried this in the win32 beta3, and it still >>>> ignores the changes you make: I went to create a new job step, >>>> selected batch, typed gibberish in the name and definition, unchecked >>>> 'read only', and erased the generated SQL and replaced it with "select >>>> 'hello'", and then clicked OK, and it added the gibberish step (rather >>>> than doing nothing, which is what select-hello should've done...) So >>>> 'read only' doesn't seem to be useful at this point. >>> Oh, I see what you mean. If memory serves, the pgAgent dialogues >>> process their SQL in a slightly different way to all the other >>> dialogues because they need to run some parts in different steps. >>> >>> Guillaume; this is your code ( :-p ) - do you see a simple way to fix >>> it, or should the checkboxes be disabled on the three pgAgent >>> dialogues? >>> >> Actually, it's not really useful in that context. We should simply >> disable the checkbox on these dialogs. Perhaps we don't even need an SQL >> tab? > > I think it's still useful to display the SQL, if only to allow the > user to see what pgAdmin is going to do. Disabling (better yet, > removing) the checkbox on those dialogues seems like the right answer. > > Can you do that in the next day or so? > I'll work on a patch for this tonight. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Guillaume Lelarge a écrit : > Dave Page a écrit : >> On Mon, Jun 8, 2009 at 10:23 PM, Guillaume >> Lelarge<guillaume@lelarge.info> wrote: >>> Dave Page a écrit : >>>> On Mon, May 11, 2009 at 3:43 PM, Kevin Field <kevinjamesfield@gmail.com> wrote: >>>>> About editing, I just tried this in the win32 beta3, and it still >>>>> ignores the changes you make: I went to create a new job step, >>>>> selected batch, typed gibberish in the name and definition, unchecked >>>>> 'read only', and erased the generated SQL and replaced it with "select >>>>> 'hello'", and then clicked OK, and it added the gibberish step (rather >>>>> than doing nothing, which is what select-hello should've done...) So >>>>> 'read only' doesn't seem to be useful at this point. >>>> Oh, I see what you mean. If memory serves, the pgAgent dialogues >>>> process their SQL in a slightly different way to all the other >>>> dialogues because they need to run some parts in different steps. >>>> >>>> Guillaume; this is your code ( :-p ) - do you see a simple way to fix >>>> it, or should the checkboxes be disabled on the three pgAgent >>>> dialogues? >>>> >>> Actually, it's not really useful in that context. We should simply >>> disable the checkbox on these dialogs. Perhaps we don't even need an SQL >>> tab? >> I think it's still useful to display the SQL, if only to allow the >> user to see what pgAdmin is going to do. Disabling (better yet, >> removing) the checkbox on those dialogues seems like the right answer. >> >> Can you do that in the next day or so? >> > > I'll work on a patch for this tonight. > Here it is. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Вложения
On Tue, Jun 9, 2009 at 9:06 PM, Guillaume Lelarge<guillaume@lelarge.info> wrote: >>> I think it's still useful to display the SQL, if only to allow the >>> user to see what pgAdmin is going to do. Disabling (better yet, >>> removing) the checkbox on those dialogues seems like the right answer. >>> >>> Can you do that in the next day or so? >>> >> >> I'll work on a patch for this tonight. >> > > Here it is. Hmm, not sure I like that - it assumes that we'll never be able to edit pgAgent SQL, and does so far away from the pgAgent code which could easily lead to future confusion. Can we disable/hide the control on each individual dialogue please? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page a écrit : > On Tue, Jun 9, 2009 at 9:06 PM, Guillaume Lelarge<guillaume@lelarge.info> wrote: >>>> I think it's still useful to display the SQL, if only to allow the >>>> user to see what pgAdmin is going to do. Disabling (better yet, >>>> removing) the checkbox on those dialogues seems like the right answer. >>>> >>>> Can you do that in the next day or so? >>>> >>> I'll work on a patch for this tonight. >>> >> Here it is. > > Hmm, not sure I like that - it assumes that we'll never be able to > edit pgAgent SQL, and does so far away from the pgAgent code which > could easily lead to future confusion. > > Can we disable/hide the control on each individual dialogue please? > Yes, we can. I was lazy yesterday, and didn't want to go much deeper in the code :) New patch is attached. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Вложения
On Wed, Jun 10, 2009 at 8:51 PM, Guillaume Lelarge<guillaume@lelarge.info> wrote: > Dave Page a écrit : >> Can we disable/hide the control on each individual dialogue please? >> > > Yes, we can. I was lazy yesterday, and didn't want to go much deeper in > the code :) > > New patch is attached. Ouch - using EnableReadOnly(false) to switch into read only mode gives me a headache! I changed it to SetSqlReadOnly(true); Thanks! -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page a écrit : > On Wed, Jun 10, 2009 at 8:51 PM, Guillaume > Lelarge<guillaume@lelarge.info> wrote: >> Dave Page a écrit : >>> Can we disable/hide the control on each individual dialogue please? >>> >> Yes, we can. I was lazy yesterday, and didn't want to go much deeper in >> the code :) >> >> New patch is attached. > > Ouch - using EnableReadOnly(false) to switch into read only mode gives > me a headache! I changed it to SetSqlReadOnly(true); > You're right, your commit is more easier to understand than my patch :) Sorry for your headache :) -- Guillaume. http://www.postgresqlfr.org http://dalibo.com