Bootrec is the "fdisk /mbr" for Windows Vista and Windows 7.
If you got here and you still have a C drive letter assigned and that drive is accessible, then the suggestions above might work. I suggest you try them first.
If you don't have a system drive letter, then the resolution is fairly simple:
Start the repair option from a Windows 7 installation disk.
It detected that there were issues with the current Vista installation and fixed them. We rebooted the system and all was well again. No data loss and still running Vista.
We used a Windows 7 Ultimate x64 disk to fix a Windows Vista Ultimate x32 OS.
Examples of different types of cursors. Each has its own pros and cons. Example 1 is the most straightforward and easiest to understand. The variants in example 3 perform better. I've put them here for reference.
-- 1) implicit cursor
DECLARE l_old_tbs VARCHAR(100) := 'USERS';
BEGIN
FOR item IN (
SELECT OWNER, TABLE_NAME FROM ALL_TABLES WHERE TABLESPACE_NAME = l_old_tbs )
LOOP
dbms_output.put_line(item.TABLE_NAME);
END LOOP;
END;
-- 2) explicit cursor
DECLARE l_old_tbs VARCHAR(100);
CURSOR c1 IS (SELECT OWNER, TABLE_NAME FROM ALL_TABLES WHERE TABLESPACE_NAME = l_old_tbs);
BEGIN
l_old_tbs := 'USERS'; -- set variable here, otherwise it is NULL!
FOR item IN c1 LOOP
dbms_output.put_line(item.TABLE_NAME);
END LOOP;
END;
-- 3a) local collection variable with multiple fields using BULK COLLECT and FORALL
CREATE TABLE TEST1 (OWNER VARCHAR(30), TABLE_NAME VARCHAR(30));
DECLARE l_old_tbs VARCHAR(100);
TYPE r_tmp IS RECORD (OWNER ALL_TABLES.OWNER%TYPE, TABLE_NAME ALL_TABLES.TABLE_NAME%TYPE);
TYPE t_tmp IS TABLE OF r_tmp;
tmp t_tmp;
BEGIN l_old_tbs:= 'USERS';
-- fill local collection "tmp" with one bulk operation
SELECT OWNER, TABLE_NAME BULK COLLECT INTO tmp FROM ALL_TABLES WHERE TABLESPACE_NAME = l_old_tbs;
-- update/insert/delete with one bulk operation; select not permitted.
-- no "loop" keyword, because following statement is performed as one batch. Check dbms_output, this is only one line.
-- always use "commit" statement
FORALL i IN tmp.FIRST..tmp.LAST
INSERT INTO TEST1 VALUES tmp(i);
dbms_output.put_line('first: 'tmp.FIRST', last: 'tmp.LAST);
COMMIT;
END;
-- 3b) local collection variable with single field using BULK COLLECT and FORALL
DECLARE l_old_tbs VARCHAR(100);
TYPE t_tmp IS TABLE OF ALL_TABLES.TABLE_NAME%TYPE;
tmp t_tmp;
BEGIN
l_old_tbs:= 'USERS';
-- fill "tmp" with one bulk operation
SELECT TABLE_NAME BULK COLLECT INTO tmp FROM ALL_TABLES WHERE TABLESPACE_NAME = l_old_tbs;
-- update/insert/delete with one bulk operation; select not permitted.
-- no "loop" keyword, because following statement is performed as one batch.
-- always use "commit" statement
FORALL i IN tmp.FIRST..tmp.LAST
INSERT INTO TEST1 (TABLE_NAME) SELECT tmp(i) FROM DUAL;
COMMIT;
END;
-- 3c) local collection variable with multiple fields using BULK COLLECT and FOR
SET SERVEROUTPUT ON;
SET SERVEROUTPUT ON SIZE UNLIMITED;
DECLARE
l_old_tbs VARCHAR2(100);
TYPE r_tmp IS RECORD (OWNER ALL_TABLES.OWNER%TYPE, TABLE_NAME ALL_TABLES.TABLE_NAME%TYPE);
TYPE t_tmp IS TABLE OF r_tmp;
tmp t_tmp;
BEGIN
l_old_tbs:= 'USERS';
-- fill local collection "tmp" with one bulk operation
SELECT OWNER, TABLE_NAME BULK COLLECT INTO tmp FROM ALL_TABLES WHERE TABLESPACE_NAME = l_old_tbs;
-- update/insert/delete with one bulk operation; select not permitted.
-- with "loop" statement. Check dbms_output, there are as much lines as tmp.LAST.
-- always use "commit" statement
FOR i IN 1..tmp.COUNT
LOOP
--INSERT INTO TEST1 VALUES tmp(i);
dbms_output.put_line('tablename: '||tmp(i).TABLE_NAME||', last: '||tmp.LAST);
COMMIT;
END LOOP;
END;
-- 3d) local collection variable with single field using BULK COLLECT and FOR
SET SERVEROUTPUT ON;
SET SERVEROUTPUT ON SIZE UNLIMITED;
DECLARE
i INT := 0;
l_tabname VARCHAR2(100);
TYPE r_tmp IS RECORD (TABLE_NAME USER_TABLES.TABLE_NAME%TYPE);
TYPE t_tmp IS TABLE OF r_tmp;
tmp t_tmp;
BEGIN
-- fill local collection "tmp" with one bulk operation
SELECT TABLE_NAME BULK COLLECT INTO tmp FROM USER_TABLES WHERE UPPER(TABLE_NAME) LIKE 'TTMP_%';
-- update/insert/delete with one bulk operation; select not permitted.
-- with "loop" statement. Check dbms_output, there are as much lines as tmp.LAST.
-- always use "commit" statement
FOR i IN 1..tmp.COUNT
LOOP
dbms_output.put_line(i);
l_tabname := 'DROP TABLE ' || tmp(i).TABLE_NAME;
dbms_output.put_line(l_tabname);
EXECUTE IMMEDIATE l_tabname;
COMMIT;
END LOOP;
END;
-- 4) use a temp table
CREATE GLOBAL TEMPORARY TABLE tmp (OWNER VARCHAR(30), TABLE_NAME VARCHAR(30);
Start with just the sqldeveloper.conf adjustment. If that doesn't fix it, then perform all steps.
Steps to solve the issue:
Links: http://ask-leo.com/what_is_limited_connectivity_and_how_do_i_fix_it.html
Sysocmgr.exe /i:sysoc.ini
Windows Registry Editor Version 5.00... or you can set the DWord keyvalue to 0 by hand.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]"ClassicShell"=dword:00000000
=IIF([boolean],[return value if true],[return value if false])A problem lies in the fact that both the true and the false part are obligatory. For setting the color the following IIF-statement can be used:
=IIF(ReportItems!txtBox.Value=5, "Palegreen", "Transparent")But, the value Transparent does not exist! You cannot set it! Visual Studio throws the following warning:
The value of the background color property for the textbox ‘textbox’ is “Transparent”, which is not a valid background color.It turns out that this property is not exported to the generated XML file, called rdl, if it is not explicitly set. The IIF-statement forces you to set it, but the value Transparent cannot be used. How to dynamically set the color property then?
function Rank(val1)Can you have the IIF-statement return a null (uninitialized object) value? The System.DBNull value that has replace the null value is just a type, not a value. So, this doesn't work.
if val1=5 then Rank = "Palegreen"
end function
EXEC sp_MSforeachtable "IF LEFT('?',11)='[dbo].[STG_' BEGIN PRINT '?' TRUNCATE TABLE ? END"The statement expects a strict naming convention: all staging table names should start with STG_ and this prefix should not be used for any other table types. Also make sure you do not have any "permanent" data in your staging environment.