Does anyone have an idea how you can catch the exception that cobol throws if you try to open an IO file if it doesn't exist, and then create a new file?
The OPTIONAL phrase on the SELECT cause will do this:
SELECT OPTIONAL FILE-A
ASSIGN TO "INFILE"
ORGANIZATION INDEXED.
If OPEN IO the file will be created if necessary. For OPEN INPUT, the file not be created but treated as being at EOF and all random reads will be "INVALID KEY".
I'm pretty sure this is an ANSI standard clause, but can't remember when it showed up.
I don't know what version of Cobol you use or what platform you use it on. My program checks first to see if the file exists before it tries to open it. I use Unisys Cobol 85 on the MCP mainframe platform. The messages are lame, but who cares?
Here is a snippet from a job that runs daily:
968545 IF ATTRIBUTE RESIDENT OF OU3-WORK-LIST-FILE = VALUE TRUE
968550 DISPLAY "PROGRAM SHOWS ATTRIBUTE TRUE"
968555 OPEN EXTEND OU3-WORK-LIST-FILE
968560 ELSE
968565 DISPLAY "PROGRAM SHOWS FALSE"
968570 OPEN OUTPUT OU3-WORK-LIST-FILE
968575 END-IF.
968580
Cathy
Related
I am new to postgres, probably missing something silly like (the correct name of my directory). Can someone guide me?
I am following book instructions, Practical SQL by Anthony DeBarros
Code:
copy us_counties_2010 from 'C:\Users\obella\OneDrive\Desktop\us_counties_2010.csv' with (FORMAT CSV, HEADER);
Error:
ERROR: could not open file
"C:\Users\obella\OneDrive\Desktop\us_counties_2010.csv" for reading:
Permission denied HINT: COPY FROM instructs the PostgreSQL server
process to read a file. You may want a client-side facility such as
psql's \copy. SQL state: 42501
copy us_counties_2010 from
'C:\Users\obella\OneDrive\Desktop\us_counties_2010.csv' with (FORMAT
CSV, HEADER);
Expected:
Query returned successfully: 3143 rows affected
Actual:
ERROR: could not open file
"C:\Users\obella\OneDrive\Desktop\us_counties_2010.csv" for reading:
Permission denied HINT: COPY FROM instructs the PostgreSQL server
process to read a file. You may want a client-side facility such as
psql's \copy. SQL state: 42501
All that is to be done is:
Go to Properties of that particular file by right clicking on it. Then, go to Security tab of the displayed Properties dialog box. Click on Edit option. Permissions dialog box appears, then click on Add button. Type 'Everyone' (without apostrophes) in the "Enter the object names to select" description box and click on OK button. Then, make sure all the checkboxes of "Permissions for Everyone" are selected by just ticking the "Full Control" check box to allow the control access without any restriction. Then, Apply and OK all the tabs to apply all the changes done.
You can now run/execute the query without any errors.
As the message tells you, Postres is not allowed to read the file.
If you want to fix that open the Task Manager, and click on "Show processes from all users". Look for the rows with the image name postgres.exe (likely more than one). Remember the value in the column "User Name" (it's probably NETWORK SERVICE). Open the properties of your file, add that user in the "Security" tab and grant read access to them.
Or use psql's \copy as the message suggests.
copy us_counties_2010 (your column name)//(country_code, latitude, longitude, country, population)
FROM 'D:\us_counties_2010 .csv' DELIMITER ',' csv HEADER
Your csv file should be in other than C drive. It can't access your C drive. Store it in D drive or any other it will work perfect.
Change the Location of data file and path to Drive['D:\us_counties_2010.csv' ] it will work.
The permission is denied because your files[us_counties_2010.csv] is in 'C' Drive ['C:\Users\obella\OneDrive\Desktop\us_counties_2010.csv'] which is a Windows Drive and permissions are restricted and may not be changed easily & impossible without administrative privileges.
Good Luck & happy programming!
If you are using PSQL, run it as administrator, then you shouldn't have any problem when you are using COPY
In the case when creating a table as well as importing data from a CSV file, we can skip the query and use the program itself. To do this, simply right-click on your table in the tree on the left and select the Import/Export… menu item.
A window will appear with the slider set to Import. Then select the source file and set the format to CSV. Set the Header to Yes if your file has a header. The only thing left is to select the delimiter (usually a comma).
When you click OK, the data will be imported.
For a better understanding, you can refer original article.
https://learnsql.com/blog/how-to-import-csv-to-postgresql/
copy us_counties_2010 from 'C:\Users\obella\OneDrive\Desktop\us_counties_2010.csv' with (FORMAT CSV, HEADER,DELIMITER ',');
Use this code instead of that
I experienced an error in SAP ABAP which says DATASET_CANT_CLOSE with error number 32 (Broken Pipe). Question is: what procedure triggered this kind of error?
As far as I know, this error was triggered by:
CLOSE DATASET dset
But I can't reproduce the error since I don't know what procedure does trigger this kind of error.
This is the code I use:
method GENERATE_TXT_FILE.
DATA :
lwa_data TYPE t_line,
lv_param TYPE sxpgcolist-parameters.
"Upload File to Server
*Open Dataset
OPEN DATASET im_file_name FILTER 'dos2ux'
FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.
CLEAR lwa_data.
LOOP AT it_data INTO lwa_data.
CATCH SYSTEM-EXCEPTIONS file_access_errors = 4
OTHERS = 8.
TRANSFER lwa_data-lines TO im_file_name.
ENDCATCH.
IF sy-subrc <> 0.
CLEAR lwa_data.
EXIT.
ENDIF.
CLEAR lwa_data.
ENDLOOP.
*Close Dataset
CLOSE DATASET im_file_name.
As I have investigated through the background job log, it seems that the current server which run the background job haven't got mapped yet to the text file folder. Solution is to re-map the server to text file folder.
You are using the FILTER extension to OPEN DATASET - which can be a HUGE security issue as well as raise loads of portability issues unless you know what you're doing, but that's not what the question is about. From the documentation:
When the statement OPEN DATASET is executed, a process is started in
the operating system for the specified statement. When the file is
opened for reading, a channel (pipe) is linked with STDOUT of the
process, from which the data is read during file reading. The file
itself is linked with STDIN of the process. When the file is opened
for writing, a channel (pipe) is linked to STDIN of the process, to
which data is passed when writing. The output of the process is
diverted to this file.
In your case, the filter command probably decided to bail out - see this answer among many. Why is hard to investigate - you may have to go through various system logs to find out. If the problem really is some unmapped network folder, you could try switching to UNC paths.
First, this question relates to Oracle SQL Developer 3.2, not SQL*Plus or iSQL, etc. I've done a bunch of searching but haven't found a straight answer.
I have several collections of scripts that I'm trying to automate (and btw, my SQL experience is pretty basic and mostly MS-based). The trouble I'm having is executing them by a relative path. for example, assume this setup:
scripts/A/runAll.sql
| /A1.sql
| /A2.sql
|
/B/runAll.sql
/B1.sql
/B2.sql
I would like to have a file scripts/runEverything.sql something like this:
##/A/runAll.sql
##/B/runAll.sql
scripts/A/runAll.sql:
##/A1.sql
##/A2.sql
where "##", I gather, means relative path in SQL*Plus.
I've fooled around with making variables but without much luck. I have been able to do something similar using '&1' and passing in the root directory. I.e.:
scripts/runEverything.sql:
#'&1/A/runAll.sql' '&1/A'
#'&1/B/runAll.sql' '&1/B'
and call it by executing this:
#'c:/.../scripts/runEverything.sql' 'c:/.../scripts'
But the problem here has been that B/runAll.sql gets called with the path: c:/.../scripts/A/B.
So, is it possible with SQL Developer to make nested calls, and how?
This approach has two components:
-Set-up the active SQL Developer worksheet's folder as the default directory.
-Open a driver script, e.g. runAll.sql, (which then changes the default directory to the active working directory), and use relative paths within the runAll.sql script to call sibling scripts.
Set-up your scripts default folder. On the SQL Developer toolbar, Use this navigation:
Tools > Preferences
In the preference dialog box, navigate to Database > Worksheet > Select default path to look for scripts.
Enter the default path to look for scripts as the active working directory:
"${file.dir}"
Create a script file and place all scripts associated in it:
runAll.sql
A1.sql
A2.sql
The content of runAll.sql would include:
#A1.sql;
#A2.sql;
To test this approach, in SQL Developer, click on File and navigate and open the script\runAll.sql file.
Next, select all (on the worksheet), and execute.
Through the act of navigating and opening the runAll.sql worksheet, the default file folder becomes "script".
I don't have access to SQL Developer right now so i can't experiment with the relative paths, but with the substitution variables I believe the problem you're seeing is that the positional variables (i.e. &1) are redefined by each start or #. So after your first #runAll, the parent script sees the same &1 that the last child saw, which now includes the /A.
You can avoid that by defining your own variable in the master script:
define path=&1
#'&path/A/runAll.sql' '&path/A'
#'&path/B/runAll.sql' '&path/B'
As long as runAll.sql, and anything that runs, does not also (re-define) path this should work, and you just need to choose a unique name if there is the risk of a clash.
Again I can't verify this but I'm sure I've done exactly this in the past...
you need to provide the path of the file as String , give the patch in double quote it will work
**
For Example
#"C:\Users\Arpan Saini\Zions R2\Reports Statements and Notices\Patch\08312017_Patch_16.2.3.17\DB Scripts\snsp.sql";
**
Execution of Sql
#yourPath\yourFileName.sql
How to pass parameters in file
#A1.sql; (Parameter)
#A2.sql; (Parameter)
This is not absolute or relative path issue. It's the SQL interpreter issue, where by default it will look for files which are having .sql extention.
Please make sure to modify the file name to file_name.sql
Ex: if workspace is having file name called "A", then move the file from A to "A.sql"
Hi community!
I have an application in VB.Net, in the user's computer is located in program files.
The users run always the program as an Administrators.
But in some cases; when the program try to rename a file in the program files the program throws the following exception:
The given path's format is not supported.
SOURCE = System.Security.Util.StringExpressionSet.CanonicalizePath
Also, happens when I try to copy a file.
The application does the rename or copy automatically and it's the same name for all the users
Example:
Rename(vOld, vNew)
FileCopy(vOld, vNew)
This exception only happen in Win7.
Somebody have an idea what is the reason to some users appear this exception?
This will happen when the user provides an invalid file name, for example one that includes colons.
You should validate that the user-entered file name does not contain any of the values in System.IO.Path.GetInvalidPathChars.
All it's my fault!
-_-'
I'm trying to rename this path:
C:\_MyFile.xlsx
To:
C:\MyFile.xlsx
In my computer all works fine because I have the both files (The users only has the file with the underscore).
When the program try to validate it try to rename the file "_C:\MyFile.xlsx" to "C:\MyFile.xlsx"
The exception don't give much information about my error...
Please have a look at the following code
with text_io;
use text_io;
procedure hello is
begin
put_line("hello");
new_line(3);
end hello;
When I click "build all" in GPS IDE, I get this error
gnatmake -d -PC:\Users\yohan\firstprogram.gpr
firstprogram.gpr:1:06: literal string expected
firstprogram.gpr:2:01: "end" expected
gnatmake: "C:\Users\yohan\firstprogram.gpr" processing failed
[2013-04-03 13:29:58] process exited with status 4 (elapsed time: 00.47s)
I am very new to Ada, as you can see, this is my first program. Please help.
On the command line, gnatmake will happily compile a file which contains Ada code but has the extension .gpr. GPS knows "better" than that, and insists on treating myfirstprogram.gpr as a GNAT Project file, which of course it isn't.
You'll find life with GNAT much easier if you stick with its file naming conventions: .ads for a spec, .adb for a body, and the file name needs to be the unit name in lower case. In your case, the file should have been called hello.adb.
The simplest approach to creating a GNAT project file in GPS is to go to the Project menu and select New. The only places where you must enter data are on the "Naming the project" page (you might choose firstproject!) and the "Main files" page, where you'd click on the blue + to add hello.adb; you can Forward through the others.
After adding the main file, you can click Apply to install the new project file; now you can Build all and Run.
You may find the GPS tutorial helpful (Help menu, GPS ...)