first I have to say: My VB and SQL is limited to the absolute basics. I'm still studying and don't really have a real idea how working with databases works in VB (or in general).
My current task for work is: I've been given a 10 year old program, coded by an ex-employee. This program is written and based on visual studio (a lot of windows forms) and is basically just a database management tool. It's supposed to show the stored data sets and give the user the option to import excel files and add data manually. The program worked pretty good so far, but some of the dropdown menus do not write the selected value into the database, but instead just leave the field empty. I'm supposed to fix that.
Now at first I thought it'd be really easy. Just look at the code of the save-button and check if the insert command contains the correct names of the database fields. After a bit of searching (the code is uncommented and basically a mess) I've found the function that gets called when the save button is clicked. This function takes an SqlDataAdapter and calls the method "InsertCommand" with a stored procedure and the database connection as parameters. Then it adds the different parameters and executes the procedure.
My problem is: Where can I find the stored procedure and how do I change it? I'm guessing there's simply a typo in there for the dropdown fields or something, but since I can't see it and actually don't really have a clue what a stored procedure is, I don't know how to proceed.
Sadly I'm not allowed to post the code, but I hope my explanations are enough for you guys to understand my problem. I don't want you to fix my problem, but rather point me in the right direction - am I completely wrong here, or is my route a good guess?
Thanks in advance, let me know if you need more information!
The Stored Procedure will be in the Database.
Assuming its an MS-SQL database, open Sql Server management studio, find the database, and look under the "Programmability" folder - you should see the stored proc in there.
Related
We have a code that is quite long, that we want to put into VBA Excel. For extracting the outstanding balance of all our customers account (we're a bank sort of). But To write the code takes to long because we have to reformat it etc etc..... So what do you suggest we use?
Im not sure wether I should put in what we've thought about, I don't want to steer your recommendations here.....But we've looked into FUNCTIONS, PROCEDURES and VIEWS. All for the purpose of finding lets call it a "container" which we can put our code in and then put it into VBA, and then make sure that it understands what is inside this container, so that it executes the code and gets us the outstanding balance + some more info.
Thannks!
Using a SQL VIEW / Stored Proc is a better idea than creating queries in Excel. It'll be pre-compiled so will run quicker, and it means you can call it from other places than Excel.
If you put all the definition for a query in Excel, then you'll need to use Excel to get that same info, or copy that Excel routine to somewhere else (and that's when mistakes start to happen). Adhere to DRY (Don't Repeat Yourself).
I would just create a stored SQL procedure or a VIEW, server-side and then just call it from Excel with whatever parameters you like to pull in the right data, keep it nice and simple on the Excel side.
I need a way to search my entire Oracle database for a column that contains the value 'Beef'. What I need is the column name and table name so I can complete my query. Beef is an animal feed type and it is a known value in my database. I just don't know where.....
Essentially, we have a very old very clunky application that I am using SQL data sets generated from Toad freeware to get around. The application shows us laboratory testing information for our companies. The catch is you can only look at one company's lab report at a time, and as a I said, it takes FOREVER. We have over 700 companies we regulate so this is not an option (oh and you can't copy any of the fields).
I have already generated a query that gets me 99% of the information I need until I realized I was missing one column value that for some unearthly reason isn't included with the other attributes of the lab samples. We have around 100 or so tables and many of them aren't even in use. It's a poorly organized database and I've tried manually going through it and simply cannot find the stupid column and I have no idea what it could be named (naming conventions here seem not to apply).
A monkey wrench is: although I've done a decent amount of SQL coding for my job I'm not in IT. My job hooked me up with a read-only access of our database so I could run reports for them etc, but I'm not in the IT section so I don't get write privileges. So a lot of solutions I see that use DDL aren't available to me.
I guess it might be relevant, it looks like we're running oraClient10g.
I've tried this code that I got from here: community.Oracle
but as you can see I don't get any results.
I also tried the one suggested here at stackOverflow, but got a litany of errors so I abandoned that pretty quick. (I figured it's because of my read-only privileges and or my version of Oracle).
Any help would be greatly appreciated.
Ok, so the background to the story. I am largely self taught the bits of SQL i do know, and it tends to be just enough to make things work that need to work - albeit with a fair bit of research for the most basic jobs!
I am using a piece of software which grabs a string of data, and then passes it straight to an SQL stored procedure to move the data around, perform a few tasks on the string to make it the format i need it to be, and then grabs lumps of this data and places it in various SQL tables as outlined by the SP. I get maybe half a million lines of data each day, and this process works perfectly well and quickly. However, should data be lost, or not manage to make it through to the SQL database correctly, i do still have a log of the 500,000 lines of raw data in CSV file format.
I cant seem to find a way to simply bulk import this data into the various tables in the various formats it needs to be in. Assuming there is no way to re-pass this data through the 3rd party software (i have tried and failed), what is the best (read easiest for a relative lamen) way to send each line of this CSV file through my existing stored procedure, which can then process and import the data as normal? i have looked at the bcp utility, but that didnt seem to be viable (or i am not well enough informed to make it do what i need). I have also done the usual trawling of the web (and these forums) to see if anything jumped out at me as the obvious way forward, but come up a bit dry.
Apologies if i am asking something a bit 101, but i would certainly be grateful if anyone could help me out with this - if i missed out any salient bits of information, let me know! :)
Cheers.
The SQL Server Import/Export Wizard is a point and click solution that can be used to import CSV files into SQL Server.
The wizard builds an SSIS package behind the scenes, which can be saved and scheduled to run as needed. The wizard doesn't give you much in the way of data transformation, but the data could be loaded into a staging table and then processed by your existing stored procedure.
IS THIS ABSOLUTELY BONKERS.....
I have just started working on a new project and I'm shocked at what I have just seen. This project is a C# web app that sits on top of an Oracle database. Now all the stored procedures are not actually stored procedures.... They are just SQL scripts stored in text files in a directory on the server. When the application starts it looks in the directory and goes through each file and reading out the text and saving it in a dictionary. It also runs a Regex over the text removing special sequences like [PARAM] and replaces them with the correct symbol e.g. ':' in Oracles case or '#' for SQL SERVER. Then when the code wants to execute one of these statements it calls a method which finds the correct one in the dictionary and runs it.
Now this appears to have been done in case they ever wanted to swap underlying db technologies. They say they would just swap the sql files out of the directory for files in the appropriate syntax and it would work.
Now I would normally expect the stored procedures to be actually stored procedures and live on the db. A separate project (layer) that talks to the db. Then if the db technology changes just add another data layer project and swap the dlls out....
I see massive problems with the way its been done currently:
No execution plan on the db server being created.
Massive overhead reading hundreds of text files, building up a string for each, running regex over it.
No checking of SQL syntax.
Big memory foot print having all these stored procedures in memory
What do you lot think?
Is this really bad or am I just moaning because I have never seen anything like this before?
What else is wrong with this approach?
Any comments will be much appreciated as I'm trying to get across to colleagues that this is crazy....
Why don't they use the scripts at build time to create stored procedure scripts in the native syntax (PSQL, T-SQL), which can then be deployed to the database? I can't see that would too much more work, and you get all the benefits of compiled stored procedure code etc.
I have personal experience of run-time compilation of stored procedures (SQL Server) being a big performance overhead, and on a production system this was a real problem.
I can sort of see the reasoning behind this design:
Stored procedure code is too database specific, so we won't use
stored procedures, we will use SQL statements instead.
Even SQL statements can have database specific syntax in them, so
we'll have some hokey method for converting them on the fly at
run-time.
Even if you don't use stored procedures, I still think the conversion should be done at build time (e.g., to generate C# code), not run-time.
What do you lot think?
I think it's a classic case of over-engineering: who changes their DB provider? Is it really bringing anything to the table?
Is this really bad or am I just moaning because I have never seen
anything like this before?
A bit of both in my opinion: it's quite bad but if they've been running like this for some time it's got to be working.
What else is wrong with this approach?
As it is, re-calculating the execution plan every time is probably the biggest issue:
so much performance loss! I'm saying probably because performance is not always a requirement (over-optimization isn't any better ;)
What is really wrong is that they reinvented the wheel: LINQ does that natively.
And that means as LINQ gets improved over time, the company will steadily fall behind since they won't benefit from the enhancements.
If you have any leverage power, try to talk to them about LINQ.
Most of my SPs can simply be executed (and tested) with data entered manually. This works well and using simple PRINT statements allows me to "debug".
There are however cases where more than one stored procedure is involved and finding valid data to input is tedious. It's easier to just trigger things from within my web app.
I have a little experience with the profiler but I haven't found a way to explore what's going on line by line in my stored procedures.
What are your methods?
Thank you, as always.
Note: I'm assuming use of SQL Server 2005+
Profiler is very handy, just add SP:StmtStarting events, and filter the activity down to just your process by setting SPID=xxx. Once you have it set up, it's a breeze to see what's going on.
You can actually attach a debugger to your sql server :) - from vs, given you have configured that on your sql server.
Check this link for more info, notice you can set break points :) https://web.archive.org/web/20090303135325/http://dbazine.com/sql/sql-articles/cook1.
Check this link for a more general set of info: http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx
Update: Regarding "There are however cases where more than one stored procedure is involved and finding valid data to input is tedious. It's easier to just trigger things from within my web app."
I suggest you set up integration tests, focused on the specific methods that interact with those procedures. If the procedures are being driven by the web app, it is a great place to have valid tests + inputs you can run at any time. If there are multiple apps that interact with the procedures, I would look at unit testing the procedures instead.
I prefer to just use stored procs for dataset retrieval, and do any complex "work" on the application side. Because you are correct, trying to "debug" what's happening inside the guts of a many layered, cursor-looping, temp-table using, nested stored proc is very difficult.
That said, MS KB 316549 describes how to use visual studio to debug stored procs.
According to this article, there are a number of limitations to debugging in this fashion:
You cannot "break" execution.
You cannot "edit and continue."
You cannot change the order of statement execution.
Although you can change the value of variables, your changes may not take effect because the variable values are cached.
Output from the SQL PRINT statement is not displayed.
Edit: Obviously, if you are the person making this stored proc, then don't make it "many layered, cursor-looping, temp-table using, and nested". In my role as a DBA, though, that's pretty much what I encounter daily from the app developers.
This trick is pretty handy:
Custom user configurable Profiler Events
As far as not knowing what the valid inputs would be, you need to test a wide range of inputs including especially invalid inputs. You should define your test cases before you write your procs. Then you have a reproducable set of tests to run every time someone changes the complex process.
My team uses SPs by rule as our interface to the database; we do it in a way that the application user can ONLY execute SPs (with our naming convention).
One best practice that we use, that works well, is that certain test scripts are contained within the SP comments, and must be executed on each rev of an SP, or development of a new SP.
You should always, ALWAYS test the SP as thoroughly as possible without any application layer involved (through Management Studio, for example).
Make sure you step into main stored proc in VS2005/2008, when it encounters a nested function, hit F11 (step into ) to enter in...continue debugging... It was not very obvious from the debug menu.
I prefer not to debug, I do test driven development instead, which almost eliminates the need to debug.