I'm trying to call IDENT_CURRENT() against a different database without moving to that database but I can't seem to find the schema it belongs to. I tried both sys and dbo but neither worked. I've searched and searched but nowhere can I find anything relating to either it's schema or how to call it.
How do you go about running such functions on another database please? I know I can most likely create a function in that database and then call my function but I'm first trying to find out whether there's an easier way.
Thanks!
IDENT_CURRENT is a function, it doesn't belong to a schema.
You can provide it with a 3-parts identifier to a table that belongs on a different database in the same server:
SELECT IDENT_CURRENT('<Database>.<Schema>.<Table>');
However you should note that ident_current might yield wrong results.
For more information, read Aaron Bertrand's For the last time, NO, you can't trust IDENT_CURRENT().
Related
I have a pretty simple stored procedure to just update the status value for a bunch of records. I send in an unknown value of record IDs and it works.
I love using Insight.Database and wouldn't want to use anything else if possible.
The problem is our DBA's created multiple User-Defined Table Types to handle situations. But their naming conventions are identical.
We have a [IntTable] with column [IntValue]
and another [TinyIntTable] with column [TinyIntValue]
Insight appears to inspect the type of UDT that could work. And sometimes it chooses [TinyIntTable] (I am guessing because the values in the array being sent are all small enough to fit into a tinyInt. But that [TinyIntTable] isn't compatible with the stored procedure. How do I force Insight.Database to always use the [IntTable]?
Is there an attribute I could use on my c# object definition?
If you’re using stored procedures, then insight will check the type of the parameter and use the correct one. i.e. it should just work.
So your problem is likely something else. Check out the table type section on the wiki, and if that doesn’t solve it for you, please post a simple example on github and we’ll help you out.
I have a model Foo which has a field called bar.
class Foo(models.Model):
bar = models.CharField(max_length=70)
Given an existing instance of Foo whose bar field is set to 'qux', the following query returns an empty QuerySet:
Foo.objects.filter(bar__icontains="qux")
However, if I reference/save the previous instance or I create/save a new Foo, I am able to find it using a similar query.
So, how can I find old, existing records using icontains?
Djangae's documentation makes specific reference to using contains and icontains, but I see no mention of this particular behavior or how to address it. (I do see the index being added to djangaeidx.yaml) I also see nothing in the Migration documentation which makes me think I need to explicitly add an index or similar.
The answer can be found in the 0.9.10 migration guide.
In this situation, you'd need to run something like:
defer_iteration(Foo.objects.all(), Foo.save, _target="your-new-app-version")
in order to add the necessary indexes to existing records.
While this worked, it definitely feels heavy handed to me. I'd be happy to hear from anyone else who might have an alternative solution.
I'm trying to search all tables and columns in a database, a la here. The suggested technique is to construct SQL query strings and then EXEC them. This works well, as a stored procedure. (Another example of variable table/column names is here. Again, EXEC is used to execute "dynamic SQL".)
However, my app requires that I do this in a function, not an SP. (Our development framework has trouble obtaining results from an SP.) But in a function, at least on SQL Server 2008 R2, you can't use EXEC; I get this error:
Invalid use of a side-effecting operator 'INSERT EXEC' within a function.
According to the answer to this post, apparently by a Microsoft developer, this is by design; it has nothing to do with the INSERT, only the fact that when you execute dynamically-constructed SQL code, the parser cannot guarantee a lack of side effects. Therefore it won't allow you to create such a function.
So... is there any way to iterate over many tables/columns within a function?
I see from BOL that
The following statements are valid in a function: ...
EXECUTE
statements calling extended stored procedures.
Huh - How could extended SP's be guaranteed side-effect free?
But that doesn't help me anyway:
The extended stored procedure, when it is called from inside a
function, cannot return result sets to the client. Any ODS APIs that
return result sets to the client will return FAIL. The extended stored
procedure could connect back to an instance of SQL Server; however, it
should not try to join the same transaction as the function that
invoked the extended stored procedure.
Since we need the function to return the results of the search, an ESP won't help.
I don't really want to get into extended SP's anyway: incrementing the number of programming languages in the environment would complicate our development environment more than it's worth.
I can think of a few solutions right now, none of which is very satisfactory:
First call an SP that produces the needed data and puts it in a table, then select from the function which merely reads the result from the table; this could be trouble if the search takes a while and two users' searches overlap. Or,
Have the application (not the function) generate a long query naming every table and column name from the db. I wonder if the JDBC driver can handle a query that long. Or,
Have the application (not the function) generate a long series of short queries naming every table and column name from the db. This will make the overall search a lot slower.
Thanks for any suggestions.
P.S. Upon further searching, I stumbled across this question which is closely related. It has no answers.
Update: No longer needed
I think this question is still valid, and we may again have a situation where we need it. However, I don't need an answer anymore for the present problem. After much trial-and-error I managed to get our application framework to retrieve row results from the RDBMS via the JDBC driver from the stored procedure. Therefore getting the thing to work as a function is unnecessary.
But if anyone posts an answer here that helps with the stated problem, I will be happy to upvote and/or accept it as appropriate.
An sp is basically a predefined sql statment with some add ons.
So if you had
PSEUDOCODE
Create SP_DoSomething As
Select * From MyTable
END
And you can't use the SP
Then you just execute the SQL as in "Select * From MyTable"
As for that naff sql code.
For start you could join table to column with a where clause, which would get rid of that line by line if stuff.
Ask another question. Like How could this be improved, there's lots of scope for more attempts than mine.
I'm currently doing some maintenance on an application and I've come across a big issue regarding the qualified name in tsql. I wondering if someone could clear my confusion up for me.
From my understanding you want to use USE [DatabaseName] to declare which database you are using. I notice if u "rename" the databse it automatically updates these references in your code.
However, the developer who originally wrote this code used the USE [DatabaseName]. Then in later statements he wrote: SELECT * FROM [DatabaseName].[dbo].[Table]. Well this obviously breaks if I change the Database's name. From what i've read you want to qualify names only to the owner such as: [dbo].[TableName] so it knows where to look which increases performance.
Is there a reason he included the Database name in each statement?
From what i've read you want to qualify names only to the owner such as: [dbo].[TableName] so it knows where to look which increases performance.
Not that I'm aware of, rather it looks like someone is lazy.
I always use the three name format (unless accessing a linked server instance, then it's four).
The benefit is that the correct table from the correct database & schema will be used without concern for an errant USE [appropriate database] statement. As long as the object exists, and the permissions are valid based on the need, you can recreate a stored procedure, function, view, etc in other databases without needing to address the USE [appropriate database] statement each time.
But I'm working with data spread over numerous databases on the same instance. I wouldn't have necessarily designed it that way, but it wouldn't change that I use three (or four) part qualified name format.
I need to test whether various types of database objects exist in a given database, and I don't know how to formulate these tests in Firebird SQL. Each test has the form "Does object of type X with name Y exist?". For example, I need to test whether a table with a given name exists. The object types I need to test are:
Table
View
Domain
Trigger
Procedure
Exception
Generate
UDF
Role
One can find how to query for a given table on the Internet, but the other types are more difficult to find ...
I think a lot of what you are asking can be found at this forum post. If you want to dive a little deeper, this site seems to have a graphical representation of the tables.
It seems like you need to query against the system tables to reliably get that information. Here's a tutorial that looks like it can help:
http://www.alberton.info/firebird_sql_meta_info.html
Every year, Martijn Tonies made a session in Firebird Conference
so find in timetable
in 2005
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=fb_conf_timetable_2005
in 2006
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=fb_conf_timetable_2006
there is also for 2007 and 2008
http://www.firebirdconference.net/index.php?option=com_content&view=article&id=3&Itemid=3
but I don't know where to download papers