I have a stored procedure which has been well tested and works perfectly from SQL Server Management Studio. All the procedure does is check for the existence of a record in a table, return it if it exists, or create it and then return it if it doesn't.
The procedure looks like this:
CREATE proc [dbo].[spInsertSerialBatch]
#MOS_JOB varchar(12), --PASSED COMMAND LINE
#MOS_LOT varchar(4) = NULL, --PASSED COMMAND LINE
#MES_USER varchar(12) = 'NOT PASSED',--PASSED COMMAND LINE
#COMPUTERNAME varchar(100) = 'NOT PASSED' --ENVIRONMENT VARIABLE
as ....
I use a SqlDataAdapter, which I have used repeatedly without any problems. The setup looks like this:
using (SqlCommand sqlComm = new SqlCommand("dbo.spInsertSerialBatch", serialBatchDataConnection))
{
if (serialBatchDataConnection.State != ConnectionState.Open)
{
serialBatchDataConnection.Open();
}
sqlComm.CommandType = CommandType.StoredProcedure;
sqlComm.Parameters.AddWithValue("#MOS_JOB", options.jobNumber);
sqlComm.Parameters.AddWithValue("#MOS_LOT", options.lotNumber);
sqlComm.Parameters.AddWithValue("#MES_USER", options.userId);
sqlComm.Parameters.AddWithValue("#COMPUTERNAME", System.Environment.MachineName);
SqlDataAdapter sda = new SqlDataAdapter(sqlComm);
DataTable dt = new DataTable();
int rowsAffected = sda.Fill(dt);
}
I then examine the results of the table after Fill is executed. It works fine when the row exists in the table, but if it doesn't, and the stored proc needs to generate it, Fill returns 0 rows and the data table remains empty. No errors/exceptions are thrown, I just get no results.
I suppose I could change the code to use ExecuteNonQuery and not use the DataAdapter, but I see no reason why this shouldn't just work; I prefer having a data table (which may result in more than a single row in some cases) than using a data reader and looping over the data to get the results.
Any suggestions as to why this might fail? I've looked over several posts on this and other sites that are similar, but haven't found a satisfactory answer. Any suggestions are greatly appreciated.
Thanks,
Gary
The entrire sp is quite large and probably too proprietary to publish...
--return inserted rows
SELECT 'CREATED' as [spRESULT], o.*
FROM #output o
END
/*
* Return existing SerialBatch(s)
*/
BEGIN
SELECT 'RETRIEVED' as [spRESULT], s.*
FROM SerialBatch s
WHERE SerialBatchId = #formattedId
UNION
/*
* pull in products that have components that need labels as well
*/
SELECT 'RETRIEVED' as [spRESULT],s.*
FROM SerialBatch s
WHERE SerialBatchParentId = #formattedId
END
This is the end of the stored procedure. I tried executing a DataReader instead and the result is the same...I get no results for the case when the sp has to create it, but again it runs perfectly stand-alone in SQL Server Management Studio.
Problem solved. Turns out that the OpenQuery string passed to Oracle was converting an empty string to a NULL and preventing the new row from being returned. All I need to add was a check for both NULL and empty string:
if #MOS_LOT IS NULL or #MOS_LOT = ''
set #MOS_LOT = ' ' --EMPTY STRINGS BEING EQUIVALENT TO NULLS
Related
How do I insert into a FoxPro table with a primary key whose default value isnewid("tablename") using Microsoft's OLE DB Provider for Visual Foxpro 9.0?
I have two tables, one where the primary key has a default value of newid("tablename"), and the other whose data type is set to Integer (AutoInc).
When I try to run the same insert command on the newid table, I get the following OleDbException:
Feature is not available
When I run insert on the table with Integer (AutoInc) as the primary key, it works.
Here is the code I am trying to execute:
public void InsertData()
{
using(var connectionHandler = new OleDbConnection("Provider=VFPOLEDB.1;Data Source=\"C:\\path\\to\\db.dbc\";"))
{
var insertStatement = #"INSERT INTO mytable (mycol) values (?)";
var insertCommand = new OleDbCommand(insertStatement, connectionHandler);
insertCommand.Parameters.Add("mycol", OleDbType.Char).Value="blue";
connectionHandler.Open();
insertCommand.ExecuteNonQuery();
connectionHandler.Close();
}
}
Is there any reason OLE would not be able to execute an insert because of this newid() default value?
Another case that fixes my issue is if I manually specify an id in the insert clause. ex:
var insertStatement = #"INSERT INTO mytable (id, mycol) values (?, ?)";
insertCommand.Parameters.Add("id", OleDbType.Integer).Value = 199;
insertCommand.Parameters.Add("mycol", OleDbType.Char).Value = "blue";
Additionally, I am able to run a select * from tablename on this table.
select snippet:
public DataTable GetData()
{
var myData = new DataTable();
using(var connectionHandler = new OleDbConnection("Provider=VFPOLEDB.1;Data Source=\"C:\\path\\to\\db.dbc\";"))
{
var da = new OleDbDataAdapter();
var mySQL = "select * from mytable";
var myQuery = new OleDbCommand(mySQL, connectionHandler);
connectionHandler.Open();
da.SelectCommand = myQuery;
da.Fill(myData);
connectionHandler.Close();
}
return myData;
}
newid() SP:
function newId
parameter thisdbf
regional keynm, newkey, cOldSelect, lDone
keynm=padr(upper(thisdbf),50)
cOldSelect=alias()
lDone=.f.
do while not lDone
select keyvalue from main!idkeys where keyname=keynm into array akey
if _tally=0
insert into main!idkeys (keyname) value (keynm)
loop
endif
newkey=akey+1
update main!idkeys set keyvalue=newkey where keyname=keynm and keyvalue=akey
if _tally=1
lDone=.t.
endif
enddo
if not empty(cOldSelect)
select &cOldSelect
else
select 0
endif
return newkey
In a separate stored procedure, I have tried the following to isolate the key word regional:
FUNCTION GetHello
regional hello
RETURN "HELLO WORLD"
Which seems to work (for example, setting the default value of a column to GetHello() then running an insert over OLEDB).
The following causes my stored procedure to fail with "Feature is not available" over OLEDB:
FUNCTION GetHello
LOCAL test
test="select * from customer"
&test
RETURN "hello"
Thanks for sharing the SP code! It shows what was the culprit.
Though my nerves tend to do many corrections on that code I will only modify enough to make it work from both VFP and C#:
function newId
parameter thisdbf
regional keynm, newkey, nOldSelect, lDone
keynm=padr(upper(thisdbf),50)
nOldSelect=select()
lDone=.f.
do while not lDone
select keyvalue from main!idkeys where keyname=keynm into array akey
if _tally=0
insert into main!idkeys (keyname) value (keynm)
loop
endif
newkey=akey+1
update main!idkeys set keyvalue=newkey where keyname=keynm and keyvalue=akey
if _tally=1
lDone=.t.
endif
enddo
Select (m.nOldSelect)
return newkey
The changed part is only related to that (if !empty(...)) block.
The issue is this variable declaration line in the stored procedure:
regional keynm, newkey, cOldSelect, lDone
The 'regional' keyword is a holdover from the old FoxPro 2.6 for DOS\Windows. It was only used in programs generated by the screen builder tool. It obviously still lurks within Visual FoxPro to support functionality that migrates old FoxPro 2.6 projects to Visual FoxPro, because the code works fine in VFP. But the OLEDB driver doesn't support it.
Anyway, you need to change your stored procedure to use:
local keynm, newkey, cOldSelect, lDone
... and recompile it, for which you will need Visual FoxPro. Ensure there are no OLEDB or other connections to it and then in the Visual FoxPro command window:
compile c:\path\to\mydatabase.dbc
This is my first time posting, so please let me know if I made a mistake or if my question is poorly worded. I am currently working on an utility app that allows data from several different csv files to be uploaded into a database for reporting purposes.The App takes the files, combines them, and removes duplicates. Once the database is generated any new file can be uploaded to update the database or insert new records.
I looked around and I couldn't find a solution for my problem. At the moment I am having trouble updating the database with new data.
For some reason, whenever I try to update the data using the following stored procedure, none of the changes are saved in the database.
CREATE PROCEDURE [dbo].[UpdateDeviceReport]
#SerialNumber AS VARCHAR(32),
#DeviceType AS VARCHAR(8),
#InstalledOn AS VARCHAR(32),
#PortStatus AS CHAR(6)
AS
BEGIN
UPDATE computer
SET deviceType = #DeviceType, deviceInstalledOn = #InstalledOn
WHERE serialID = #SerialNumber
UPDATE computer_localblocker
SET portStatus = #PortStatus
WHERE computer_serialid = #SerialNumber;
END
GO
Here is the C# code that executes the procedure.
public void updateOrgDevices()
{
using (var conn = new SqlConnection(PopulateDatabase.connectionString))
{
int debug = 0;
conn.Open();
foreach (KeyValuePair<string, DictionaryObjs> element in GlobalVariables.UpdateData)
{
OrgDevRepObj obj = element.Value as OrgDevRepObj;
SqlCommand sqlCommand = new SqlCommand("UpdateDeviceReport", conn);
sqlCommand.CommandType = CommandType.StoredProcedure;
sqlCommand.Parameters.Add("#SerialNumber", SqlDbType.VarChar, 32).Value = obj.SerialNumber.Trim().ToUpper();
sqlCommand.Parameters.Add("#DeviceType", SqlDbType.VarChar, 8).Value = obj.DeviceType;
sqlCommand.Parameters.Add("#InstalledOn", SqlDbType.VarChar, 32).Value = obj.InstalledOn;
sqlCommand.Parameters.Add("#PortStatus", SqlDbType.Char, 6).Value = obj.PortStatus;
debug = sqlCommand.ExecuteNonQuery();
}
}
}
The parameters come from a dictionary/hashmap, GlobalVariables.UpdateData, that stores data rows as objects where the key is the serial number from that row of data(e.g. Dictionary<string[serial Number], DictionaryObjs>) and the values of the fields for each data row are stored as strings, in a class called DictionaryObjs. This is the parent class for all record types. In this case the record type is OrgDevRepObj.
I was able to get the code to work once, but I haven't been able to replicate it. It doesn't throw any errors, but I know its not working because sqlCommand.ExecuteNonQuery(); returns a -1 for each dictionary key value pair. I've also tried using
sqlCommand.Parameters.AddWithValue('#Param', [value]);
Any ideas?
Could you possibly have set NOCOUNT ON globally? See msdn.microsoft.com/en-us/library/ms176031.aspx
Try adding SET NOCOUNT OFF to your stored procedure.
An idea to test according to your situation, create a table called test with a single varchar type field and inside the procedure you make an insert to that table by inserting the SerialNumber. This way you can tell if it is filtering by the correct serial and if the procedure is executed. Luck…
Note: my office doesn't allow me to view YouTube and several other sites that probably have the answer to this question on them (they are blocked), which is why Googling the answer hasn't yielded results.
ComboBox code reference: found here
On my C# Form, I have filled a ComboBox with tables from a database (see below code), which returns the appropriate values and functions correctly:
public Form1()
{
InitializeComponent();
// Connection
SqlConnection conn = new SqlConnection();
conn.ConnectionString = "CONNECTION STRING" // shortened for security and convenience
// Fill ComboBox with SQL Values
conn.Open();
SqlCommand cmbTables = new SqlCommand("SELECT name FROM sys.tables", conn);
SqlDataReader read = cmbTables.ExecuteReader();
DataTable cmbData = new DataTable();
cmbData.Columns.Add("name", typeof(string));
cmbData.Load(read);
cmb1.DisplayMember = "name";
cmb1.DataSource = cmbData;
conn.Close();
}
After the ComboBox loads the tables (which works), the application then selects a table and clicks a button that loads the table, which is selected. This is where the code errors:
private void button1_Click(object sender, EventArgs e)
{
using (var connection = Utilities.GetConnection())
{
string table = Convert.ToString(txt1.Text);
string cmb1Value = Convert.ToString(cmb1.SelectedItem);
// Stored Procedure
SqlCommand select = new SqlCommand("EXECUTE STOREDPROCEDURE" + cmb1Value, connection); // shortened for security and convenience
select.Parameters.Add(new SqlParameter(cmb1Value, table));
// Data View
SqlDataAdapter ad= new SqlDataAdapter(select);
ad.SelectCommand = select;
DataTable dt = new DataTable();
ad.Fill(dt); // this generates the error "Incorrect Syntax Near '.'"
BindingSource b = new BindingSource();
b.DataSource = dt;
dGrid.DataSource = b;
ad.Update(dt);
connection.Close();
}
}
Even though the ComboBox loads the appropriate values, from the above code, I may be missing something which attaches those values to the SELECT stored procedure (all it does is call SELECT statement through a variable passed to it). The error, "Incorrect Syntax Near '.'" looks like a SQL Server error that I've seen, but can't remember how I generate it (this is how I usually troubeshoot where the TSQL code went wrong).\
Stored Procedure Related code:
C#:
SqlCommand select = new SqlCommand("EXECUTE STOREDPROCEDURE " + cmb1Value, connection);
TSQL:
CREATE PROCEDURE [STOREDPROCEDURE]
#TableName VARCHAR(250)
AS
BEGIN
DECLARE #sql NVARCHAR(MAX)
SET #sql = N'SELECT TOP 100 *
FROM ' + #TableName
EXECUTE(#sql)
END
-- Note this works in SSMS without a problem.
The above code is incorrect, and when I tweak the TSQL code, I generate similar errors, telling me that somewhere I am missing a conversion, or another variable because SQL Server isn't seeing these table values returned by the SELECT (first block of code). I can ascertain this because I have a second ComboBox that uses similar code EXCEPT that I populated the ComboBox with manual values, and it connects to the tables in the database with no error. So, the ComboBox, which grabs values from the database, that you see above, does not function correctly.
For instance, if I only add the below line of code to the code, I receive an error that it can't find the database "EXECUTE STOREDPROCEDURE System'
select.CommandType = CommandType.StoredProcedure;
However, System isn't a part of anything, so where did that come from? It never errored with this code on the manual ComboBox, as it had no trouble finding the database (using the same connection string, server and database!).
If I try to use a TSQL parameter, such as:
SqlCommand select = new SqlCommand("EXECUTE stp_ReturnTable #p", scon);
select.Parameters.Add(new SqlParameter("#p", cmb1Value));
Suddenly, it can't find the stored procedure. Again, the connection strings are identical for the manual ComboBox and the dynamic ComboBox.
I think the code behind the dynamic ComboBox is wrong. When I'm out of the office, I'll review some videos with detailed demonstrations on how to create a dynamic ComboBox from a database and I have a hunch that a system object is in the way (based on the System error, which exists nowhere in my code, as well as it suddenly being unable to find the database or procedure).
The missing key point in your code is the CommandType.
Without the proper set of this property the default is CommandText and thus the Framework expects a statement that starts with SELECT/INSERT/UPDATE/DELETE etc....
using (var connection = Utilities.GetConnection())
{
string table = Convert.ToString(txt1.Text);
string cmb1Value = Convert.ToString(cmb1.SelectedItem);
// Stored Procedure
SqlCommand select = new SqlCommand("STOREDPROCEDURE", connection);
select.Parameters.Add(new SqlParameter("#TableName", cmb1Value));
// That's the key to let ADO.NET accept the previous CommandText as valid.
// If you omit this the CommandText is assumed to be a SELECT/UPDATE/DELETE etc..
select.CommandType = CommandType.StoredProcedure;
// Data View
SqlDataAdapter ad= new SqlDataAdapter(select);
DataTable dt = new DataTable();
ad.Fill(dt);
BindingSource b = new BindingSource();
b.DataSource = dt;
dGrid.DataSource = b;
}
EDIT Having seen the code of the SP then you could simply set the SqlParameter name to the constant #TableName and pass the value extracted from the combobox as the value to be used inside the SP
EDIT I have looked again at your code and I suspect that the culprit is the line
string cmb1Value = Convert.ToString(cmb1.SelectedItem);
Looking at how you have filled your combo, this line, doesn't return the tablename as you expect, but the generic string System.Data.DataRowView because the DataSource of the combo is a DataTable and not a string collection. You should try to change that line in this way
DataRowView rw = cmb1.SelectedItem as DataRowView;
if(rw != null)
{
string cmbValue1 = rw["name"].ToString();
....
And yes, your code should work also without the CommandType.StoredProcedure line because the text EXECUTE sp param is recognized as a valid sql commandtext (but why do you use it when a direct call to the storedprocedure could be optimized for reuse?)
I have a performance problem with displaying data from an SQL database in my application. The problem is that I have a large number of parameters that I need to display (customers personal data, his current statistics etc.).
So far I've used either SqlCommand.ExecuteScalar (for single parameters), or DataTable.Rows[].ItemArray.GetValue() (for multiple parameters - I fill the DataTable with SqlDataAdapter whose query withdraws the necessary data from the database) and assigned their values to the appropriate control. Assuming that command is an SqlCommand type:
For single parameter
command.CommandText = "SELECT Parameter1 FROM MyTable WHERE Condition = Value";
textBox1.Text = command.ExecuteScalar().ToString();
For multiple parameters (SDA is a SqlDataAdapter):
command.CommandText="SELECT Parameter1 - ParameterN FROM MyTable WHERE Condition = Value";
SDA.SelectCommand = command;
SDA.Fill(MyDataTable);
textBox1.Text = MyDataTable.Rows[0].ItemArray.GetValue(0).ToString();
comboBox1.Text = MyDataTable.Rows[0].ItemArray.GetValue(1).ToString();
/*
I repeat similar lines of code for each parameter and display it in the appropriate control.
*/
This approach works correctly but when I have a large number of parameters (20+), it works very slowly.
Is there a more efficient way to display these amounts of data, and how would I implement it?
Thank you
Probably, with the second example, a SqlDataReader will perform better because you read the values just one time, while with a DataAdapter, you need to load the DataTable and then loop over the rows of the table (Effectively reading data two times).
command.CommandText="SELECT Field1,...,FieldN FROM MyTable WHERE Condition = Value";
SqlDataReader reader = command.ExecuteReader();
while(reader.Read())
{
// Of course this works correctly just if your query returns one row....
textBox1.Text = reader.GetString(0);
comboBox1.Text = reader.GetString(n);
}
You could also try with the Field<T> extension for the DataRow
command.CommandText="SELECT Field1,...,FieldN FROM MyTable WHERE Condition = Value";
SqlDataAdapter SDA = new SqlDataAdapter(command);
SDA.Fill(MyDataTable);
textBox1.Text = MyDataTable.Rows[0].Field<string>("Field1");
comboBox1.Text = MyDataTable.Rows[0].Field<string>("FieldN");
However, I think that the real performance gain would be in the query that you submit to the database engine and in the correct working of indexes on your tables.
Try to retrieve the minimun number of rows possible, search on indexed fields and/or change to a stored procedure.
here i had write sample stored procedure in wich you can get idea...
you can pass as amny parameter as you can in xml format and insert into temp table...
now you have table with value Name/value pair means Paramater name /value....
now you can do your furteher work...
/*
EXEC wa_TempGetDaya '<SampleXML>
<tblXML><AccountID>3</AccountID><Code>11</Code><Description>Leptospiral infect NEC</Description></tblXML>
</SampleXML>'
*/
CREATE PROCEDURE wa_TempGetDaya
(
#ParaXML NVARCHAR(MAX)
)
AS
SET NOCOUNT ON
BEGIN
DECLARE #AccountID INT
DECLARE #MyXML XML
SET #MyXML = #ParaXML
IF OBJECT_ID('tempdb..#TempData') IS NOT NULL
DROP TABLE #TempData
SELECT * INTO #TempData
FROM (
SELECT
Parse.value('(AccountID)[1]', 'INT') AS 'AccountID',
Parse.value('(Code)[1]', 'Varchar(100)') AS 'Code',
Parse.value('(Description)[1]', 'varchar(1000)') AS 'Description'
FROM
#MyXML.nodes('/SampleXML/tblXML') AS YourData(Parse)
) AS tbl
declare #para1 varchar(20)
declare #para2 varchar(20)
declare #para3 varchar(20)
SELECT #para1 =AccountID ,#para2 =Code,#para3 =Description from #TempICD
END
I am facing this problem. I have a stored procedure which returns 6 rows when I execute it.
But when I am retrieving the rows in my app by using ExecuteReader, it only returns only 5 rows. Why is it losing a row??
My stored procedure consists of 5 union statements which are getting filled from a single table:
dbase.AddInParameter(cmd, "#LoginUser", DbType.String, UserID);
try
{
using (IDataReader dr = dbase.ExecuteReader(cmd))
if (dr.Read())
{
dt = new DataTable("DashBoard");
dt.Load(dr);
}
}
dbase is my database object. And cmd is the SqlCommand used to call the stored procedure.
UserID is parameter is passing
Stored procedure code is:
ALTER PROCEDURE [dbo].[USP_ViewAdminDashBoard](#LoginUser varchar(75))
-- Add the parameters for the stored procedure here
AS
BEGIN
SET NOCOUNT ON;
SET DATEFORMAT DMY;
DECLARE #LastLoginDate as DateTime
Select #LastLoginDate = dbo.UDF_GetLastLoginByUser(#LoginUser)
Select 'Last Login Date', convert(varchar(12),#LastLoginDate,105)
Union
Select 'Nos. Records pending for Upload' as Title, convert(varchar(5),COUNT(s.BatchID)) Total from dbo.BREGISTRATIONENTRY s, Dbo.TBL_iBATCH B
where B.BatchID = s.BatchID And b.Forwarded = 0 and b.isBatchClosed = 1
END
Your first dr.Read is advancing to the first row. The DataTable.Load is reading the remaining rows but not the first row
Use HasRows to test for existence and don't use Read before the DataTable.Load
Edit:
Just load the DataTable without testing first: then test on the DataTable. There is no HasRows in the IDataReader interface.
IDataReader is a forward reader,it means when you read a row,that row will be deleted from the reader and you can't get it from the reader any more.
joshua i also has this problem while using enterprise library more than two time even i use same code written down but both time i found a problem in my store procedure there must be any wrong selection in query or any think else which db server does not detect and i solve it and
my IDataReader select all rows and also use same way as suggest by 'gbn'
using (IDataReader dr = oDb.ExecuteReader(p_oDbCommand))
{
if (dr != null)
{
ds.Tables[0].Load(dr);
}
}
return dt;