Hi,
I want set a specific port number of SQL Server(express) during installation not by Configuration Manager after install.
Is it possible?
hi,
probably becouse of the multi instances support of SQL Server up to version 2000, which introduced the SQL Server Resolution Service listening on UDP 1434, now SQLBrowser, this feature has been removed from the configurable settings..
but you can interact via SMO as well, but probably after your installer has finished..
regards
Hello,
I'm trying to update a single field of a record and i want to do it using a standard multi line text box but I'm not sure how to write the c# command to process the sql update. I would also like the entry to be added into the database with line breaks.
Thanks for your help
There is nothing to ask..... you can do it using the same way u r updating the others.... you do not need any c# command.... its the query on which all this depends...
you can use query... : update <table name> set <feild name>= textbox1.text where <condition>....
and about multi lines.... you do not need to worry about line breaks..... the data would be stored in the database just as the way it is in the multiline textbox.... and would be fetched in the same manner...
and do tell me if its any worthy 4 u or not.
|||Ok - In theroy I get what your saying but then I have VisStudio post out the code I need to make the text box and the supporting data source and I get all of this:
----------------
<asp:TextBox ID="txtNotes" runat="server"></asp:TextBox>
<asp:SqlDataSource ID="sqlUpdateNotes" runat="server" ConnectionString="<%$ ConnectionStrings:dbNetOps %>" DeleteCommand="DELETE FROM [MasterServerlist] WHERE [ID] = ?" InsertCommand="INSERT INTO [MasterServerlist] ([ID], [Notes]) VALUES (?, ?)" ProviderName="<%$ ConnectionStrings:dbNetOps.ProviderName %>" SelectCommand="SELECT [ID], [Notes] FROM [MasterServerlist] WHERE ([ID] = ?)" UpdateCommand="UPDATE [MasterServerlist] SET [Notes] = ? WHERE [ID] = ?">
<DeleteParameters>
<asp:Parameter Name="ID" Type="Int32" />
</DeleteParameters>
<UpdateParameters>
<asp:Parameter Name="Notes" Type="String" />
<asp:Parameter Name="ID" Type="Int32" />
</UpdateParameters>
<SelectParameters>
<asp:ControlParameter ControlID="gvServers" Name="ID" PropertyName="SelectedValue"
Type="Int32" />
</SelectParameters>
<InsertParameters>
<asp:Parameter Name="ID" Type="Int32" />
<asp:Parameter Name="Notes" Type="String" />
</InsertParameters>
</asp:SqlDataSource>
------------------
What I'm trying to do is :
1: display the contents of the notes field in the text box where the record matches the record selected in a gridview element
2: have the onchange event of the notes field then post back an update to the database and redisplay the new notes in the text field
I'm very new to ASP and appriciate your help.
Thank you
|||
I cannot find anything wrong in your code... could you please describe your problem in details...... or what kind of errors you are receiving(if any).....
And also you wanted to store all the data in the textbox to the database with the line breaks.... you should set the textmode attribute of textbox to multiline...
I don't know if this is a bug or something I've messed up in my settings. I am using SQL Server Management Studio with SQL 2005 service pack 1 installed, and I've been using it successfully ever since SP1 came out. All of a sudden, any time I have a query with a single line comment (i.e. using dash dash -- ), the rest of the query is ignored as if the single line comment is really a multi-line comment without the closing */
An example:
select top 100 *
from myTable
-- this is a comment
where myTableID = 1234
This would normally return exactly one row, but instead returns 100 rows ( as if the where clause did not exist). If I move the where clause above the comment, it works as expected. Any ideas?
In trying to fix this, I've uninstalled and reinstalled and even reinstalled SP1, but it still isn't fixed.
You've got me stumped. I took the code you have posted and it ran fine for me.
Can you post the exact code that you are using? Maybe we'll see that hanging character you missed or somthing.
|||I used the exact query, merely changing the table name and ID column.
I ended up going through the process yet again (uninstalling the tools, reinstalling the tools, then installing SP1) and rebooted but still had the problem. However, after a second reboot, it starting behaving properly again. I hope my problem does not resurface.
|||We (me a colleague of mine), have withnessed this same behaviour and, atfer some deep analysis, we have concluded that this bug arises when the Transact-Sql line terminates with a CR (Carriage Return, Ascii(13)) only charaters when it should terminate with both CR (Carriage Return, Ascii(13)) followed by an LF (Line Feed, Ascii(10))It seems that once SqlServer reachs a single-line comment identifier (--) it keeps fetching bytes untill a compounded line termination (CR followed by LF) is reached.
In the following sample, the {CR+LF} and {CR} are representations of their respective invisible ascii codes.
--This is just a normal single-line comment {CR+LF}
SELECT 'This command works fine' {CR+LF}
--This is a buggy single-line comment {CR}
SELECT 'This command does not work'{CR}
SELECT 'This command does not work either' {CR+LF}
SELECT 'This command work fine too' {CR+LF}
Moreover we have reasons to bellieve that this bug resides in Query Editor provided with SQL Server Management Studio Express Edition (at least, this was version my colleague was using when this bug arose). Anyway, although this bug must be corrected, LF should just be ignored when dealing with Sql scripts.
Running software:
SQL Server Management Studio Express Edition
Ms SQLServer 2000 (8.0.2039)
Getting this sample you can:
- Load and execute it, using QueryAnalyzer to see the refered behaviour;
- View it, using Notepad, to see what actually happened.
I don't know if this is a bug or something I've messed up in my settings. I am using SQL Server Management Studio with SQL 2005 service pack 1 installed, and I've been using it successfully ever since SP1 came out. All of a sudden, any time I have a query with a single line comment (i.e. using dash dash -- ), the rest of the query is ignored as if the single line comment is really a multi-line comment without the closing */
An example:
select top 100 *
from myTable
-- this is a comment
where myTableID = 1234
This would normally return exactly one row, but instead returns 100 rows ( as if the where clause did not exist). If I move the where clause above the comment, it works as expected. Any ideas?
In trying to fix this, I've uninstalled and reinstalled and even reinstalled SP1, but it still isn't fixed.
You've got me stumped. I took the code you have posted and it ran fine for me.
Can you post the exact code that you are using? Maybe we'll see that hanging character you missed or somthing.
|||I used the exact query, merely changing the table name and ID column.
I ended up going through the process yet again (uninstalling the tools, reinstalling the tools, then installing SP1) and rebooted but still had the problem. However, after a second reboot, it starting behaving properly again. I hope my problem does not resurface.
|||We (me a colleague of mine), have withnessed this same behaviour and, atfer some deep analysis, we have concluded that this bug arises when the Transact-Sql line terminates with a CR (Carriage Return, Ascii(13)) only charaters when it should terminate with both CR (Carriage Return, Ascii(13)) followed by an LF (Line Feed, Ascii(10))It seems that once SqlServer reachs a single-line comment identifier (--) it keeps fetching bytes untill a compounded line termination (CR followed by LF) is reached.
In the following sample, the {CR+LF} and {CR} are representations of their respective invisible ascii codes.
--This is just a normal single-line comment {CR+LF}
SELECT 'This command works fine' {CR+LF}
--This is a buggy single-line comment {CR}
SELECT 'This command does not work'{CR}
SELECT 'This command does not work either' {CR+LF}
SELECT 'This command work fine too' {CR+LF}
Moreover we have reasons to bellieve that this bug resides in Query Editor provided with SQL Server Management Studio Express Edition (at least, this was version my colleague was using when this bug arose). Anyway, although this bug must be corrected, LF should just be ignored when dealing with Sql scripts.
Running software:
SQL Server Management Studio Express Edition
Ms SQLServer 2000 (8.0.2039)
Getting this sample you can:
- Load and execute it, using QueryAnalyzer to see the refered behaviour;
- View it, using Notepad, to see what actually happened.
