I'm trying to detect whether a database has a specific full text catalog so that I can either use it or avoid executing part of a script that would create errors without the catalog. I know in sql server 2005 you can use:
IF EXISTS(SELECT 1 FROM sys.fulltext_catalogs WHERE name = 'catalog_name')
But we have to support sql server 2000 still and I can't use that. Is there another way to check for the catalog?
The ##version check might need altering, but this should work:
declare #catalogExists tinyint
set #catalogExists = 0
if (##version like ('%SQL%Server%2000%')) begin
if exists(SELECT 1 FROM [master].[dbo].[sysfulltextcatalogs] WHERE name = 'catalog_name')
set #catalogExists = 1
end
else begin
IF EXISTS(SELECT 1 FROM sys.fulltext_catalogs WHERE name = 'catalog_name')
set #catalogExists = 1
end
print #catalogExists
Related
In the code below (stored procedure body), whether the value of the cursor field is automatically updated after UPDATE or not? If not, is the Close / Open command sufficient again or not?
I didn't find any description that included this, it was just the FOR SELECT cursors in all of them.
DECLARE VARIABLE FCU_VALIDATE TYPE OF COLUMN FCU_CTRL.FCU_VAL_WHEN_IMP;
DECLARE FCU_DOC_MSTR CURSOR FOR
(SELECT * FROM FCU_DOC_MSTR
WHERE FCU_DOC_APN = :APNUMBER
AND FCU_DOC_ID = :DOCID);
BEGIN
OPEN FCU_DOC_MSTR;
FETCH FIRST FROM FCU_DOC_MSTR;
-- CHECK CONTROL FILE SETTINGS
FCU_VALIDATE = COALESCE((SELECT FCU_VAL_WHEN_IMP FROM FCU_CTRL
WHERE FCU_INDEX1 = 1), FALSE);
IF (FCU_VALIDATE = TRUE) THEN
BEGIN
-- IF EXIST INVALID ITEM DETAIL LINE, SET DOCUMENT STATUS TO INVALID
IF ((SELECT COUNT(*) FROM FCU_ITEM_DET
WHERE FCU_ITEM_APN = :FCU_DOC_MSTR.FCU_DOC_APN
AND FCU_ITEM_DOC_ID = :FCU_DOC_MSTR.FCU_DOC_ID
AND FCU_ITEM_STATUS != '0') > 0) THEN
UPDATE FCU_DOC_MSTR
SET FCU_DOC_STATUS = '90'
WHERE CURRENT OF FCU_DOC_MSTR;
END
-- CHECK DOCUMENT STATUS IS IMPORTED AND NO ERROR EXIST SET STATUS TO IMPORTED
IF (FCU_DOC_MSTR.FCU_DOC_STATUS = '99') THEN
UPDATE FCU_DOC_MSTR
SET FCU_DOC_STATUS = '0'
WHERE CURRENT OF FCU_DOC_MSTR;
IF (FCU_VALIDATE = TRUE) THEN
BEGIN
IF (FCU_DOC_MSTR.FCU_DOC_STATUS = '0') THEN
UPDATE FCU_DOC_MSTR
SET FCU_DOC_STATUS = '1'
WHERE CURRENT OF FCU_DOC_MSTR;
-- UPDATE FILE STATUS
IF ((SELECT COUNT(*) FROM FCU_DOC_MSTR
WHERE FCU_DOC_FILE_ID = :FCU_DOC_MSTR.FCU_DOC_FILE_ID
AND FCU_DOC_STATUS != '1') > 0) THEN
UPDATE FCU_FILE_MSTR
SET FCU_FILE_STATUS = '90'
WHERE FCU_FILE_ID = :FCU_DOC_MSTR.FCU_DOC_FILE_ID;
ELSE
UPDATE FCU_FILE_MSTR
SET FCU_FILE_STATUS = '1'
WHERE FCU_FILE_ID = :FCU_DOC_MSTR.FCU_DOC_FILE_ID;
END
CLOSE FCU_DOC_MSTR;
END
If the update is done through the cursor (using UPDATE ... WHERE CURRENT OF _cursor_name_), then the cursor record variable for the current row is also updated.
See this fiddle for a demonstration.
This was not documented in the Firebird 3.0 Release Notes, but it was documented in the doc/sql.extensions/README.cursor_variables.txt included with your Firebird installation. This is also been documented in the Firebird 3.0 Language Reference, under FETCH:
Reading from a cursor variable returns the current field values. This
means that an UPDATE statement (with a WHERE CURRENT OF clause)
will update not only the table, but also the fields in the cursor
variable for subsequent reads. Executing a DELETE statement (with a
WHERE CURRENT OF clause) will set all fields in the cursor variable
to NULL for subsequent reads
I need validate dynamic Fields from a Table. For example:
CREATE TRIGGER BU_TPROYECTOS FOR TPROYECTOS
BEFORE UPDATE AS
DECLARE VARIABLE vCAMPO VARCHAR(64);
BEGIN
/*In then table "TCAMPOS" are the fields to validate*/
for Select CAMPO from TCAMPOS where TABLA = TPROYECTOS and ACTUALIZA = 'V' into :vCAMPO do
Begin
if (New.:vCAMPO <> Old.:vCampo) then
/*How i get dynamic New.Field1, New.Field2 on query return*/
End;
END ;
The question is : How can I put "The name of the field that the query returns me " in the above code .
Ie if the query returns me the field1 and field5 , I would put the trigger
if ( New.Field1 < > Old.Field1 ) or ( New.Field5 < > Old.Field5 ) then
There is no such feature in Firebird. You will need to create (and preferably) generate triggers that will reference all fields hard coded. If the underlying table changes or the requirements for validation, you will need to recreate the trigger to take the added or removed fields into account.
I have written a cursor to search through a table looking at one bit value.
If all values are 1, I send an email. But if one value is 0 in any row, I don't send the email. The issue that I am having comes in my If statement. In SSMS, "#isComplete = 0" is breaking with only an "Incorrect syntax" error. I am not sure what I am missing here. My code is below. Thank you.
-------------------------------------------------
-- Start the INNER Cursor --
-------------------------------------------------
DECLARE #Complete int
DECLARE #isComplete Bit = 1
DECLARE INNERCur CURSOR FOR
SELECT Complete
FROM #AAEAPVS
OPEN INNERCur
FETCH NEXT FROM INNERCur INTO #Complete
WHILE ##FETCH_STATUS = 0
BEGIN
If #Complete = 0
BEGIN
#isComplete = 0
END
FETCH NEXT FROM INNERCur INTO #Complete
END
CLOSE InnerCurs
DEALLOCATE InnerCurs
-------------------------------------------------
-- INNER Curser END --
-------------------------------------------------
The incorrect syntax is that you need to use SET to assign the variable value, so change
#isComplete = 0
to
SET #isComplete = 0
And assuming you want to exit as soon as you find something that is not complete you should change your WHILE condition to
WHILE ##FETCH_STATUS = 0 AND #isComplete = 1
But most important of all, you probably don't need to use a cursor at all - you should avoid cursors in SQL if possible. You can probably just do something like this
DECLARE #isComplete Bit = 1
IF EXISTS (SELECT * FROM #AAEAPVS WHERE Complete = 0)
BEGIN
SET #isComplete = 0
END
and even that is more than you need, you can do it in a single statement
DECLARE #isComplete Bit = 1
SELECT #isComplete = 0 FROM #AAEAPVS WHERE Complete = 0
The syntax error results from not having a statement on the line. You need to use either SET or SELECT to assign a value to a variable, e.g. set #isComplete = 0.
Why, pray tell, a cursor rather than a simple EXISTS query? A far more efficient solution is:
select #isComplete = case
when exists ( select 42 from #AAEAPVS where Complete = 0 ) then 0
else 1 end;
Tip: It is helpful to tag database questions with both the appropriate software (MySQL, Oracle, DB2, ...) and version, e.g. sql-server-2014. Differences in syntax and features often affect the answers.
Below is the code i am using to create a trigger(before insert):
ALTER TRIGGER "delete_entry_before_inserting" BEFORE INSERT
ORDER 1 ON "XYZ"."ABC"
REFERENCING NEW AS "inserted"
FOR EACH ROW /* WHEN( search_condition ) */
BEGIN
IF EXISTS (select hostname from ABC WHERE hostname = inserted.hostname) THEN
UPDATE ABC
SET days_count = (days_count + 1)
WHERE hostname = inserted.hostname
ROLLBACK TRANSACTION
END IF
END
But the above thing is giving me error as: syntax error near rollback transaction on line 11
what am i doing wrong here?
You are missing a BEGIN TRANSACTION somewhere in your code.
Check this documentation.
I'm trying to figure out a way to store metadata about a column without repeating myself.
I'm currently working on a generic dimension loading SSIS package that will handle all my dimensions. It currently does :
Create a temporary table identical to the given table name in parameters (this is a generic stored procedure that receive the table name as parameter, and then do : select top 0 * into ##[INSERT ORIGINAL TABLE NAME HERE] from [INSERT ORIGINAL TABLE NAME HERE]).
==> Here we insert custom code for this particular dimension that will first query the data from a datasource and get my delta, then transform the data and finally loads it into my temporary table.
Merge the temporary table into my original table with a T-SQL MERGE, taking care of type1 and type2 fields accordingly.
My problem right now is that I have to maintain a table with all the fields in it to store a metadata to tell my scripts if this particular field is type1 or type2... this is nonsense, I can get the same data (minus type1/type2) from sys.columns/sys.types.
I was ultimately thinking about renaming my fields to include their type in it, such as :
FirstName_T2, LastName_T2, Sex_T1 (well, I know this can be type2, let's not fall into that debate here).
What do you guyz would do with that? My solution (using a table with that metadata) is currently in place and working, but it's obvious that repeating myself from the systables to a custom table is nonsense, just for a simple type1/type2 info.
UPDATE: I also thought about creating user defined types like varchar => t1_varchar, t2_varchar, etc. This sounds like something a bit sluggy too...
Everything you need should already be in INFORMATION_SCHEMA.COLUMNS
I can't follow your thinking of not using provided tables/views...
Edit: As scarpacci mentioned, this somewhat portable if needed.
I know this is bad, but I will post an answer to my own question... Thanks to GBN for the help tho!
I am now storing "flags" in the "description" field of my columns. I, for example, can store a flag this way : "TYPE_2_DATA".
Then, I use this query to get the flag back for each and every column :
select columns.name as [column_name]
,types.name as [type_name]
,extended_properties.value as [column_flags]
from sys.columns
inner join sys.types
on columns.system_type_id = types.system_type_id
left join sys.extended_properties
on extended_properties.major_id = columns.object_id
and extended_properties.minor_id = columns.column_id
and extended_properties.name = 'MS_Description'
where object_id = ( select id from sys.sysobjects where name = 'DimDivision' )
and is_identity = 0
order by column_id
Now I can store metadata about columns without having to create a separate table. I use what's already in place and I don't repeat myself. I'm not sure this is the best possible solution yet, but it works and is far better than duplicating information.
In the future, I will be able to use this field to store more metadata, where as : "TYPE_2_DATA|ANOTHER_FLAG|ETC|OH BOY!".
UPDATE :
I now store the information in separate extended properties. You can manage extended properties using sp_addextendedproperty and sp_updateextendedproperty stored procedures. I have created a simple store procedure that help me to update those values regardless if they currently exist or not :
create procedure [dbo].[UpdateSCDType]
#tablename nvarchar(50),
#fieldname nvarchar(50),
#scdtype char(1),
#dbschema nvarchar(25) = 'dbo'
as
begin
declare #already_exists int;
if ( #scdtype = '1' or #scdtype = '2' )
begin
select #already_exists = count(1)
from sys.columns
inner join sys.extended_properties
on extended_properties.major_id = columns.object_id
and extended_properties.minor_id = columns.column_id
and extended_properties.name = 'ScdType'
where object_id = (select sysobjects.id from sys.sysobjects where sysobjects.name = #tablename)
and columns.name = #fieldname
if ( #already_exists = 0 )
begin
exec sys.sp_addextendedproperty
#name = N'Scd_Type',
#value = #scdtype,
#level0type = N'SCHEMA',
#level0name = #dbschema,
#level1type = N'TABLE',
#level1name = #tablename,
#level2type = N'COLUMN',
#level2name = #fieldname
end
else
begin
exec sys.sp_updateextendedproperty
#name = N'Scd_Type',
#value = #scdtype,
#level0type = N'SCHEMA',
#level0name = #dbschema,
#level1type = N'TABLE',
#level1name = #tablename,
#level2type = N'COLUMN',
#level2name = #fieldname
end
end
end
Thanks again