Is it possible to call a MATLAB command within a stored Procedure?, something like
EXEC(MATLAB_COMMAND(Argument1,argument2))
Without any working experience concerning SQL Sever 2008, I would say no. Referring to the mysql documentation, a stored procedure is described as:
A stored routine is a set of SQL
statements that can be stored in the
server.
The idea is to store SQL queries on your SQL server.
You should proceed to other way round. Access your SQL Server from MATLAB, eventually calling stored procedures. All you need is a jdbc driver, leveraging MATLAB's Java scripting capabilities.
Related
We try to run all our reports off stored procedures, however, now I am trying to report off a 3rd party server that I cannot deploy too. I am trying to find away to store the stored procedure on Server1, but execute on Server2 but the only link is the RDL which can see both data sets. I do not think this is possible.
First time posting here, want to start by saying thanks to the community here for the amazing insights I've enjoyed over the years
I build reports with SSRS in VS2013 and currently have to paste/import MySQL statements every time I create/update the datasets. I want VS2013/SSRS to permanently refer to a local .SQL file instead of having me manually paste the query text every time I need to update it. How does I do this?
In my ideal world, I would have a folder bank full of SQL query files that VS would use to acquire data from the DB for the reports. Then all I would have to do is alter the separate, local SQL files and VS would take it from there.
I see 3 vectors for supplying the SQL query to the dataset: 1) Paste/Import the text query, 2) Table access, 3)Stored procedures. I thought there might be a way thru Stored Procedures but I'm not having any luck discovering if it's possible and how to code it from documentation and the web.
If it's useful, Visual Studio 2013 is platformed on a Windows server O/S.
Create your script as a stored procedure on the server you're querying. Configure all your reports based on that dataset to run that stored procedure. When you update the stored procedure, all reports that use that SP are affected by the code change.
Information: We are in the process of Testing our upgrade from SQL Server 2005 to SQL server 2012 on staging. In reading the documentation on features that will no longer be supported, COMPUTE (Transact-SQL) going away is going to be an issue for us.
Question: Is there any way to write out our own procedure that will take the place of the compute builtin on SQL Server 2012 that will make it seamless so when Compute is called it will function like SQL Server 2005? The alternative is we will we need to update all the SQL files, UDF's, Triggers, and stored procedures that use this built in with alternative code?
Note I have never tried to recreate a built in function before so any information on this will be very helpful for me and anyone else trying to do this in the future. Also knowing if it can be done is a plus.
Clenup: As always if this is a duplicate post indicate the link below and i will remove my post.
COMPUTE BY is not a function. I don't see how it's effects (generating additional result sets) can be replicated easily.
Replacing COMPUTE BY with a temp table and some looping should be kind of straight forward but it will be a laborious task. It's probably better to change the application so that it does not depend on multiple result sets.
I have made the recommendation of moving to SQL Server 2008 first, this will give us 4 years or so to update all the code and then we can move up to SQL Server 2012.
That sounds reasonable. By then there will be at least SQL Server 2016 so you'll have to see what other features are deleted at that point :)
I have seen a few posts here about using the native MSSQL 2008 functionality to debug and step through TSQL.
In a Visual Studio 2010 .NET C# console app, I use simple ADO.NET to send some params to a stored proc. I can run it in the debugger and see what happens in the .NET code up until the point where the SqlCommand is executed. How can I get the debugger (or any debugger) to fire on the MSSQL side so I can follow data from the C# all the way to/though the DB?
Thanks.
If you want to capture what is sent cross the wire, use SQL Profiler.
Using SQL Server Profiler
If you are having problems stepping into a stored procedure from Visual Studio:
How to: Enable Transact-SQL Debugging
Walkthrough: Debug a Transact-SQL Stored Procedure
[Please note: your mileage may vary; I've known systems where this just wouldn't work. So much so, I never try to step into TSQL any more...]
I'm trying to create a completely new database from an existing MySQL database, bringing over both data and schema, but so far the only way I've been able to do this is to first import the MySQL database into MS Access, and then into SQL Server 2005? Crazy right? Surely, there is a way that doesn't involve a tedious, custom time-consuming programming, right (perhaps using SSIS)?
A few additions to my original description above:
Its a pretty good size database (easily a few gigs).
I'm working in an MS environment (asp.net, C#)
I'm under a tight deadline so I'm looking for an automated process that requires little to no effort in the conversion process.
SSIS would be the preferred way via BIDS (VS 2005)
Thanks for all the great input!
I believe that using the phpMyAdmin tool you can script the MySQL database structure and data into a sql script. Then you simply run those two scripts on your SQL Server 2005 database and it should, in most cases, create the database and fill it with data. It's been a couple years since I had to do it myself, but as I recall that was the process I used to transfer a MySQL database to SQL Server in the past. You will probably have to alter the structure script to change some of the data types to their SQL Server equivalents, but the data should load just fine once you've got the data types all sorted.
I think you can use SQLYog to generate some fairly standard SQL which will dump out and recreate your db, with data. You may have to massage its output for SQL Server's dialect of SQL a bit, though...
The responses I received were certainly helpful, but the solution it would seem is to do a mysqldump and then run that script from SSIS, massaging the output as needed; however, AFAIK it is not possible to use VS 2005 BIDS to create an SSIS package that completely transfers a MySQL database to a SQL Server 2005 database (data and schema) using Windows Vista 64. I said AFAIK, but who knows the interwebs have much to reveal :)