Strangest error 1

[Ferdalizer]

I have an application that writes many different files and types across the network for many different departments. two of them have stopped writing and is issuing the error message of "Unable to output file". I have changed the directories and the drives and get the same messages. These should be being created by using a simple "copy to o:\dm2\"+strtran(alltr(juststem(filename))),'PS','')+".DM2" type csv. these two commands were working up until the 18th of this month so they have just stopped be able to be written and I cant tell why. any suggestions? thanks!

 

[Chris Miller]

A line break and your quoting don't make your code very concise. Could you please post your code in a codeblock?

You find the tool to do so here:


Meanwhile I recommend you first only determine the filename, store that into a variable lcOutputFilename and then do

COPY TO (lcOutputFilename) TYPE CSV

That would separate the issue of any kind of mangled syntax from a fault in the expression that generates the filename.

 

[Joe Crescenzi]

As a rule of thumb, when code like that fails, I create a tiny program to test it without relying on any other part of the system.

So, in this case, to eliminate a potential problem with the code that generates the filename, try hard coding the filename and path, and see if that throws the same error.

If that works, you'll know the problem is in the name and/or path.

If it fails, you likely have a permissions problem on the target.

 

[Gerrit Broekhuis]

If this happens on a “real” server, check the event logs. Check antivirus. Check the flename you create. Check in config the status of all installed programs; what changed on the 17th?

Regards, Gerrit

 

[Joe Crescenzi]

A line break and your quoting don't make your code very concise. Could you please post your code in a codeblock?

You find the tool to do so here:
View attachment 125

Meanwhile I recommend you first only determine the filename, store that into a variable lcOutputFilename and then do

COPY TO (lcOutputFilename) TYPE CSV

That would separate the issue of any kind of mangled syntax from a fault in the expression that generates the filename.

We posted literally at the same time, and with the same potential solution, the code that generates the filename.

I should also add that in order to confirm this, after storing the filename to a variable, it would be a good idea to see what that variable/filename is, so you could show it in a MessageBox.

MessageBox(lcOutputFilename)

 

[fredkrampe]

I have an application that writes many different files and types across the network for many different departments. two of them have stopped writing and is issuing the error message of "Unable to output file". I have changed the directories and the drives and get the same messages. These should be being created by using a simple "copy to o:\dm2\"+strtran(alltr(juststem(filename))),'PS','')+".DM2" type csv. these two commands were working up until the 18th of this month so they have just stopped be able to be written and I cant tell why. any suggestions? thanks!

When this has happened to me, it was always a character that was not allowed in the filename or path. Do messagebox("o:\dm2\"+strtran(alltr(juststem(filename))),'PS','')+".DM2") and see what gets displayed.

 

[vaxman9]

I have an application that writes many different files and types across the network for many different departments. two of them have stopped writing and is issuing the error message of "Unable to output file". I have changed the directories and the drives and get the same messages. These should be being created by using a simple "copy to o:\dm2\"+strtran(alltr(juststem(filename))),'PS','')+".DM2" type csv. these two commands were working up until the 18th of this month so they have just stopped be able to be written and I cant tell why. any suggestions? thanks!

A couple years ago, the small company I worked for was gobbled by a much larger organization. Up to then, I was somewhat in control of the server access and was able to "know" that issue like this were mine. However, the new org has a large IT/Security group and they are constantly updating/changing, etc.

A couple months back, updated programs would not work after I dropped them on the server. After a period of time (2-15 minutes), they would suddenly work. I banged my head against it for a couple days and finally raised a flag. It turned out the Security folks dumped a new EDR system on the servers and it was basically blocking any new exe. I was informed that yes, the EDR was overly aggressive and that systems across the ecosystem were being impacted as they attempted to tweak the software. After a couple of days things settled down.

It's not exactly what you are experiencing and I don't what your environment may be, but I wanted to put this out there as something you might want to investigate.
msc

 

[Chris Miller]

Yes, overall arguing by "it always worked like this before" is silly. Your car breaks down one day, even though it worked all days before. You die one day even though you lived all days before. You think that can't happen to code as there are no moving parts, no mechanics that can break? Your expression can exceed some value and outer circumstances can change, sufficient drive space, permissions, quota (which can even catch you if there is still plenty space on drives). So never argue that way.

You're confronted with finding out what changed that makes your previously working code break. Thinking "it must work, because it did work before" hinders you finding out what is essential: What changed in the outset that breaks the code? You got to take in the bullet that the code broke, that's fact. So your job is to find out why, not to argue that it can't break.

And I'm not even talking about code that never worked, just also never ran and a first usage is after lots of time. That's obviously not the case in such code creating files that obviously ran very day or other regular interval before. But nothing is strange in the end, if you finally find out.

 

[Ferdalizer]

I thank you all for your responses. after a lot of testing and code wrangling I got it to work,. I was using select statements into tables so that I could make changes to the table before copying it out. I changed the tables to cursors and commented the changes as cursors do not allow writing to. such as a replace all statement. I can deal with the varied issues with the output on the backend. still going to research the issue more but as of now I do not have any errors.

thanks

Fred

 

[Chris Miller]

cursors do not allow writing to

Classic outcome, it wasn't the line you thought that errored.

Anyway, if you create a cursor with READWRITE it can be updated with - well - SQL UPDATE or REPLACE and INSERTs and DELETEs and APPENDs, whatever.

 

[Ferdalizer]

Well hell. the app processed 6 files correctly then once again gave me the same error message. I applied the READWRITE and everything looked fine then BOOM. it started doing it again. there are 800+ gigs free on the target drive so it is not running out of room. hmmm gotta take a different tack.

 

[Ferdalizer]

Update. let me show you the code:

SELECT SEQUENCE AS RECORDID,;
LEFT(BARCODE,11) AS POSTNET,;
CODECHAR AS IMB,;
SOURCECODE,;
'' AS GREETINS,;
NAME_FIRST AS FIRSTNAME,;
'' AS MIDDLENAME,;
NAME_LAST AS LASTNAME,;
'' AS SUFFIX,;
MAILNAME AS FULLNAME,;
'' AS TITLE,;
'' AS COMPANY,;
ADDRESS1 AS STREET,;
ADDRESS2,;
'' AS ADDRESS3,;
CITY,;
STATE,;
ZIPCODE AS ZIP,;
'' AS COUNTRY,;
'' AS EMAIL,;
'' AS PHONE,;
STRTRAN(ALLTR(JUSTSTEM(LCTMPDATAFILE)),'PS','') AS UDF01_SUMMARYFIELD,;
'' AS UDF02_SUMMARYFIELD,;
'' AS UDF03_SUMMARYFIELD,;
'' AS UDF04_IDENTIFIER,;
'' AS UDF05_IDENTIFIER,;
'' AS INDUCTIONPOINT,;
'' AS INDUCTIONDATE,;
'' AS SEEDINDICATOR,;
'' AS SPLITIDENTIFIER;
FROM (LCTMPDATAFILE) INTO CURSOR TEMP_SNAIL READWRITE

SELECT SEQUENCE AS SEQUENCE,;
LEFT(BARCODE,11) AS POSTNET,;
CODECHAR AS IMB,;
SOURCECODE,;
'' AS SALUTATION,;
NAME_FIRST AS NAME_FIRST,;
'' AS NAME_MID,;
NAME_LAST AS NAME_LAST,;
'' AS SUFFIX,;
MAILNAME AS FULLNAME,;
'' AS TITLE,;
'' AS COMPANY,;
ADDRESS1 AS ADDRESS1,;
ADDRESS2 AS ADDRESS2,;
'' AS ADDRESS3,;
CITY,;
STATE,;
ZIPCODE AS ZIPCODE,;
STRTRAN(ALLTR(JUSTSTEM(LCTMPDATAFILE)),'PS','') AS VERSION;
FROM (LCTMPDATAFILE) INTO CURSOR TEMP_DMTWO READWRITE

SELECT TEMP_DMTWO

*!* SCAN
*!* DO CASE
*!* CASE LEN(ALLTR(POSTNET))= 10
*!* REPLACE POSTNET WITH LEFT(POSTNET,9)
*!* CASE LEN(ALLTR(POSTNET))= 6
*!* REPLACE POSTNET WITH LEFT(POSTNET,5)
*!* ENDCASE
*!* ENDSCAN

*!* REPLACE ALL FIRSTNAME WITH STRTRAN(ALLTR(FIRSTNAME),'"',''),;
*!* LASTNAME WITH STRTRAN(ALLTR(LASTNAME),'"',''),;
*!* FULLNAME WITH STRTRAN(ALLTR(FULLNAME),'"','')

SELECT TEMP_SNAIL

*!* SCAN
*!* DO CASE
*!* CASE LEN(ALLTR(POSTNET))= 10
*!* REPLACE POSTNET WITH LEFT(POSTNET,9)
*!* CASE LEN(ALLTR(POSTNET))= 6
*!* REPLACE POSTNET WITH LEFT(POSTNET,5)
*!* ENDCASE
*!* ENDSCAN

*!* REPLACE ALL FIRSTNAME WITH STRTRAN(ALLTR(FIRSTNAME),'"',''),;
*!* LASTNAME WITH STRTRAN(ALLTR(LASTNAME),'"',''),;
*!* FULLNAME WITH STRTRAN(ALLTR(FULLNAME),'"','')

SNAILFILE = STRTRAN(ALLTR(JUSTSTEM(LCTMPDATAFILE)),'PS','')
COPY TO 'O:\SNAILWORKS\' + (SNAILFILE) TYPE CSV
USE IN TEMP_SNAIL
RELEASE SNAILFILE
*!* ERASE TEMP_SNAIL.DBF

SELECT TEMP_DMTWO
DM2FILE = STRTRAN(ALLTR(JUSTSTEM(LCTMPDATAFILE)),'PS','')+".DM2"
COPY TO 'O:\DM2\' + (DM2FILE) TYPE CSV
USE IN TEMP_DMTWO
RELEASE DM2FILE
*!* ERASE TEMP_DMTWO.DBF

I commented out the lines above just to see, and the error went away. I don't understand why because the replace statements are minor and rare. I use them for continuity throughout the output files. the next time this arises I will compartmentalize each SQL select and process each separately then release them.

thanks for listening 8)


Fred Fattore

 

[Gerrit Broekhuis]

Perhaps one of the fields has an invalid content or is empty when it shouldn’t be. Check if the BOOM is with the same record in every run and (if yes) then check the record’s content.

Regards, Gerrit

 

[Chris Miller]

Output to a file can't fail on NULLS or any other special value, CSV output can output any data.
So the error is either not in the COPY TO line or if it still is, it's not becaue of data, but permissions on the output directory. If you can rule that, it's in one of the REPLACEs or other code you do.

You can easily find out the line of error, if you establish error handling. There are tons of resources out there on how to, including the help on ON ERROR.