Showing posts with label plan. Show all posts
Showing posts with label plan. Show all posts

Monday, March 19, 2012

Does MS plan a GUI

Hello all,

We are planning to base a product on Microsoft SQL-2005 Notification services. However, one of the required properties from this software is to provide the client administrator a user interface to configure the Instance Configuration File (ICF) and Application Definition File (ADF). Working with XML files will not do for us, once the responsibility is delegated from a developer to an administrator.

Before going into the process of writing such an application from scratch, I would like to know if Microsoft has such an enhancement on the SQL-NS roadmap, and if so, when it is scheduled to.

Does anyone have any thoughts or knowledge?

Thanks

Ziv G.

I don't have any inside knowledge into what Microsoft is planning for future releases. But in the meantime if you're using the SSNS 2005, you can develop your own SSNS GUI to create and manage instances and applications using the SSNS API. I've given a few examples on my blog. Go to http://www.sqlns.com and enter a search criteria of nmo in the textbox in the upper left hand corner of the form.

HTH...

Joe

|||

Ziv,

Drop me an email, I may be able to help with the GUI. BTW, do you work in Israel, if so where?

-- Shaul Dar (shauld@.medcon.com)

|||

Hi Joe,

Thanks for your (quick) response. I had a look at the API supplied with SQL-NS, it seems pretty extensive, and well designed. The thing is that it seems to me that creating an ad-hoc solution should be pretty quick and simple. On the other hand, constructing a true user application, that takes into account SQL-NS integrative capabilities (custom event provider, protocols and so on), while providing default values for the internal components (SMTP delivery protocol for example), taking into consideration robustness and so on, would take a considerable time to design and write.

The thing is that it seems to me like a general-purpose software, that any NS developer would find beneficial, not an application you would expect each developer to write on his own (unlike subscription/subscriber management, which would probably be integrated into customer application, and therefore cannot be supplied with the product).

In any case, I appreciate your response, and I really enjoy your blog.

Thanx, Ziv G.

|||

Hi Ziv -

>>The thing is that it seems to me that creating an ad-hoc solution should be pretty quick and simple.
>>On the other hand, constructing a true user application, that takes into account SQL-NS integrative
>>capabilities (custom event provider, protocols and so on), while providing default values for the internal
>>components (SMTP delivery protocol for example), taking into consideration robustness and so on,
>>would take a considerable time to design and write.

Agreed. Creating an instance/application is typically much faster with the ICF and ADF rather than with the API. I think the API was added to the product to pave the way for Microsoft and 3rd parties to create toolsets. I keep intending to do that for my own practice, but alas I just haven't done it yet.

Joe

|||

I know this isn't going to be a very satisfying answer but at this point in the product cycle, we're not discussing what features we're thinking about for the next version of SQL Server.

Over time, you'll see us come out with more detailed plans for the overall product. If I remember correctly, it wasn't until 1.5 years into SQL Server 2005 that we did our Tech Preview and started the ball rolling on what features we were thinking about. These things take a little time to settle out.

Thanks,

-Lukasz

|||

Hi Luksaz,

Thanks for your answer. You are right, I wanted to get a different answer, but your answer makes sense to me.

Thanx again,

Ziv G.

Does MS plan a GUI

Hello all,

We are planning to base a product on Microsoft SQL-2005 Notification services. However, one of the required properties from this software is to provide the client administrator a user interface to configure the Instance Configuration File (ICF) and Application Definition File (ADF). Working with XML files will not do for us, once the responsibility is delegated from a developer to an administrator.

Before going into the process of writing such an application from scratch, I would like to know if Microsoft has such an enhancement on the SQL-NS roadmap, and if so, when it is scheduled to.

Does anyone have any thoughts or knowledge?

Thanks

Ziv G.

I don't have any inside knowledge into what Microsoft is planning for future releases. But in the meantime if you're using the SSNS 2005, you can develop your own SSNS GUI to create and manage instances and applications using the SSNS API. I've given a few examples on my blog. Go to http://www.sqlns.com and enter a search criteria of nmo in the textbox in the upper left hand corner of the form.

HTH...

Joe

|||

Ziv,

Drop me an email, I may be able to help with the GUI. BTW, do you work in Israel, if so where?

-- Shaul Dar (shauld@.medcon.com)

|||

Hi Joe,

Thanks for your (quick) response. I had a look at the API supplied with SQL-NS, it seems pretty extensive, and well designed. The thing is that it seems to me that creating an ad-hoc solution should be pretty quick and simple. On the other hand, constructing a true user application, that takes into account SQL-NS integrative capabilities (custom event provider, protocols and so on), while providing default values for the internal components (SMTP delivery protocol for example), taking into consideration robustness and so on, would take a considerable time to design and write.

The thing is that it seems to me like a general-purpose software, that any NS developer would find beneficial, not an application you would expect each developer to write on his own (unlike subscription/subscriber management, which would probably be integrated into customer application, and therefore cannot be supplied with the product).

In any case, I appreciate your response, and I really enjoy your blog.

Thanx, Ziv G.

|||

Hi Ziv -

>>The thing is that it seems to me that creating an ad-hoc solution should be pretty quick and simple.
>>On the other hand, constructing a true user application, that takes into account SQL-NS integrative
>>capabilities (custom event provider, protocols and so on), while providing default values for the internal
>>components (SMTP delivery protocol for example), taking into consideration robustness and so on,
>>would take a considerable time to design and write.

Agreed. Creating an instance/application is typically much faster with the ICF and ADF rather than with the API. I think the API was added to the product to pave the way for Microsoft and 3rd parties to create toolsets. I keep intending to do that for my own practice, but alas I just haven't done it yet.

Joe

|||

I know this isn't going to be a very satisfying answer but at this point in the product cycle, we're not discussing what features we're thinking about for the next version of SQL Server.

Over time, you'll see us come out with more detailed plans for the overall product. If I remember correctly, it wasn't until 1.5 years into SQL Server 2005 that we did our Tech Preview and started the ball rolling on what features we were thinking about. These things take a little time to settle out.

Thanks,

-Lukasz

|||

Hi Luksaz,

Thanks for your answer. You are right, I wanted to get a different answer, but your answer makes sense to me.

Thanx again,

Ziv G.

Friday, March 9, 2012

Does displaying the estimated execution plan change anything?

Generally I would think that having a query in query analyzer and displaying
the estimated execution plan would not change anything in the system but ran
across an interesting problem today that makes me think otherwise.
On SQL Server 2000 sp3a, I have a table with 300,000 rows in it. The table
is basically a bulk insert from the SQL Error logs with an Identity column
for the primary key and int colums added for flaging error records and such.
A SQL job calls a store procedure that truncates the table and reloads it.
After that it does an update table set errorflag = 1 where logtext like
'%error%'
I found the job in an executing state for several days and investigated.
The wait time was 0, there was no blocking, and the cpu was increasing. I
killed the job and started manually trouble shooting.
The execution or just generating the estimated plan for the update statement
would never return. I cut the update statement down to just update table
set errorflag = 1 and got the same hung state. I could do selects on the
table. Next I displayed an estimated plan for update table set errorflag = 1 where pk < 20000. The returned immediately. After that everything
worked. I could display plans and run updates. So something in the system
changed.
Any ideas what?
DannyWild guess: Perhaps statistics were updated and/or created when you looked at the plan, so the
following query had a better plan?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <nomailbox@.nowhere.com> wrote in message news:Lg2ig.18341$9c7.5231@.trnddc06...
> Generally I would think that having a query in query analyzer and displaying the estimated
> execution plan would not change anything in the system but ran across an interesting problem today
> that makes me think otherwise.
> On SQL Server 2000 sp3a, I have a table with 300,000 rows in it. The table is basically a bulk
> insert from the SQL Error logs with an Identity column for the primary key and int colums added
> for flaging error records and such.
> A SQL job calls a store procedure that truncates the table and reloads it. After that it does an
> update table set errorflag = 1 where logtext like '%error%'
> I found the job in an executing state for several days and investigated. The wait time was 0,
> there was no blocking, and the cpu was increasing. I killed the job and started manually trouble
> shooting.
> The execution or just generating the estimated plan for the update statement would never return.
> I cut the update statement down to just update table set errorflag = 1 and got the same hung
> state. I could do selects on the table. Next I displayed an estimated plan for update table set
> errorflag = 1 where pk < 20000. The returned immediately. After that everything worked. I could
> display plans and run updates. So something in the system changed.
> Any ideas what?
> Danny
>

Does displaying the estimated execution plan change anything?

Generally I would think that having a query in query analyzer and displaying
the estimated execution plan would not change anything in the system but ran
across an interesting problem today that makes me think otherwise.
On SQL Server 2000 sp3a, I have a table with 300,000 rows in it. The table
is basically a bulk insert from the SQL Error logs with an Identity column
for the primary key and int colums added for flaging error records and such.
A SQL job calls a store procedure that truncates the table and reloads it.
After that it does an update table set errorflag = 1 where logtext like
'%error%'
I found the job in an executing state for several days and investigated.
The wait time was 0, there was no blocking, and the cpu was increasing. I
killed the job and started manually trouble shooting.
The execution or just generating the estimated plan for the update statement
would never return. I cut the update statement down to just update table
set errorflag = 1 and got the same hung state. I could do selects on the
table. Next I displayed an estimated plan for update table set errorflag =
1 where pk < 20000. The returned immediately. After that everything
worked. I could display plans and run updates. So something in the system
changed.
Any ideas what?
DannyWild guess: Perhaps statistics were updated and/or created when you looked a
t the plan, so the
following query had a better plan?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Danny" <nomailbox@.nowhere.com> wrote in message news:Lg2ig.18341$9c7.5231@.trnddc06...[vbcol
=seagreen]
> Generally I would think that having a query in query analyzer and displayi
ng the estimated
> execution plan would not change anything in the system but ran across an i
nteresting problem today
> that makes me think otherwise.
> On SQL Server 2000 sp3a, I have a table with 300,000 rows in it. The tabl
e is basically a bulk
> insert from the SQL Error logs with an Identity column for the primary key
and int colums added
> for flaging error records and such.
> A SQL job calls a store procedure that truncates the table and reloads it.
After that it does an
> update table set errorflag = 1 where logtext like '%error%'
> I found the job in an executing state for several days and investigated. T
he wait time was 0,
> there was no blocking, and the cpu was increasing. I killed the job and s
tarted manually trouble
> shooting.
> The execution or just generating the estimated plan for the update stateme
nt would never return.
> I cut the update statement down to just update table set errorflag = 1 and
got the same hung
> state. I could do selects on the table. Next I displayed an estimated pl
an for update table set
> errorflag = 1 where pk < 20000. The returned immediately. After that eve
rything worked. I could
> display plans and run updates. So something in the system changed.
> Any ideas what?
> Danny
>[/vbcol]