Error Cwbdb0099

having a problem downloading a file using iSeries Access Data Transfer from System i. Whenever I perform my download, I get the CWBDB0099 and SQL0420 errors shown below. I can click OK and still download the file, but I'd like to get rid of this error. What's going on and how do I fix it? --Laura Here's the error message that Laura is referring to and what I did to solve it. After researching, I couldn't find any references to the CWBDB0099 error with the SQL4020 sub-error. There were plenty of references to the CWBDB0099 error with sub-error SQL0181, which indicates an error of "Value in date, time, or timestamp string not valid." IBM's Support Document on CWBDB009 and SQL0181 tells the user to run the Display File Field Description (DSPFFD) command on the file in question and look for any date fields that have a data type of ISO. If an ISO date type field is found, IBM instructs you to change your data transfer date/time format to ISO. I ran DSPFFD on the file and there were no date fields with a data type of ISO. However, there were three packed data fields of length 5,0 and one packed date field of length 8,0. I reasoned that it was possible that one or more of those fields were being recognized as a date field by the iSeries Access Transfer program. So I decided to try IBM's fix even though it didn't strictly apply to the problem I was seeing on Laura's screen. To change the transfer's Date/Time format to ISO, I did the following: 1. On the Data Transfer from iSeries screen, I clicked on the Format Options button. 2. On the Change Data Options screen that appears, I clicked on the Date/Time tab. I then clicked on the Date format drop-down box and changed the Date format to ISO. I finally clicked on the Apply button to save the change. 3. We tried running the problematic Data Transfer again. This time, it downloaded the data without throwing up the error message. So I guess this goes to show that sometimes a good enough approach will be enough to solve a problem. Bonus: Another Way to Detect Disk Damage While I was researching my article on finding damaged objects, IBM sent me some information on running the Service Tools' Analyze Disk Surface option to detect damage objects and problems with your disk drive. Here's the drill if you want to run a more intensive disk analysis feature to find damaged objects and brewing problems with your disk drives. 1. Run the Start System Service Tools command (STRSST) and sign in. 2. Take the following options to get to the Analyze Disk Surface option: Option 3, Work with Disk Units Option 3, Work with Disk Unit Re

iSeries Excel plugin Subject: Re: SQL0420 - Character in CAST argument not valid on Data Transfer From iSeries Excel plugin From: Mike Wills Date: Thu, 2 Aug 2012 14:24:24 -0500 List-archive: List-help: List-id: Midrange Systems Technical Discussion List-post: List-subscribe: , List-unsubscribe: , Wow... I never thought of searching on CWBDB0099. I was looking at the other code. FAIL on my part. Anyway, this work-around works for the data transfer problem. I'll try it for my insert problem as well. We are still trying to figure out what changed or why we are just seeing this now. http://www.itjungle.com/fhg/fhg072711-story02.html -- Mike Wills http://mikewills.me On Thu, Aug 2, 2012 at 1:04 PM, CRPence wrote: FWiW, searching the web only on those message identifiers yielded the following link: _Solving iSeries Access Data Transfer Problems_ ... Published: July 27, 2011 http://www.itjungle.com/fhg/fhg072711-story02.html "... plenty of references to the CWBDB0099 error with sub-error SQL0181 ... clicked on the Date format drop-down box and changed the Date format to ISO ..." -- Regards, Chuck On http://archive.midrange.com/midrange-l/201208/msg00120.html 31 Jul 2012 11:41, Mike Wills wrote: We have a user that ran a query (via WRKQRY) to a file in order to download the file. She then proceeded to go through the steps she has done many, many times before to bring it into Excel using the Data Transfer plugin in Excel. Everything looks good as she goes through the wizard, our exit point software[1] logged the transaction with basically a "select * from file as fetch only" however on the final step she gets the following error: CWBDB0099 - No more data is available for the stream fetch request SQL0420 - Character in CAST argument not valid. We tried in the "regular" file transfer tool to a file and we got the same error. Then we switched to display the data and it worked. We switched it back to file and it worked then. :-/ We are on 6.1 and haven't installed any CUME in a while so there should't be any OS changes recently. Our user is on 5.4 of Client Access and on another developer's machine she is on 6.1. Both with the same problem. To add to the "weirdness", I am getting the same error doing an INSERT into a completely different file. I

files.It seems that dates greater than 2039 were causing the download to fail witherror message:CWBDB0099 - No more data is available for the stream fetch http://midrange-l.midrange.narkive.com/FxVySXpc/date-2039-error-downloading-into-excel requestSQL0181 - Value in date, time, or timestamp string not valid.The http://www.verycomputer.com/153_175446365af47be5_1.htm annoying part of the error message is the fact that it statesdates 0001 thru 9999 are valid, when in fact they are not!The field is a Date type (L) format MM/DD/YYYY.IBM's solution for the problem is to change the options for mydownload (on the pc) and error cwbdb0099 change the date format to USA instead of thedefault MDY.This is a usable workaround for myself. However, I asked if thisdefault could be changed to always be USA and could I set it for allmy users via a parameter somewhere. Unfortunately, this is a new issueand there isn't another solution. They are creating a fix that willadd the error cwbdb0099 values to an INI file that can be edited and changed. Again, ausable workaround for myself, but I'm hoping for a better solutiongoing forward, because the default date format is apparently setduring install and is then unchangable, except on a indivudualdownload process at least until the fix with the INI file is madeavailable.Should I submit a Design Change request on this that would allow moreflexibilty during the install as well as after via an interfacedialog? I argued with the support rep, that the solution beingprovided was a good workaround, but ultimately, the user should beable to do this without having to edit an INI. Also, the century datecutoff should be more flexible.Opninions, comments, questions?Thanks,--Ron Adams--This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing listTo post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.orgTo subscribe, unsubscribe, or change list options,visit: http://lists.midrange.com/mailman/listinfo/midrange-lor email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.orgBefore posting, please take a moment to review the archivesat http://archive.midrange.com/midrange-l. f***@public.gmane.org 2008-03-05 17:23:50 UTC PermalinkRaw Message There are iSeries Access Policies that can be set at the system level. It would seem th

I try to use the AS400 to PC data transfer and query the same table twice. Here's what I'm trying to do: Select the street name twice from the same table, once for the "through street" and again for the "cross street" at an accident. In other words, get "Pine at Elm". So, each accident has it's own unique key, so I joined the tables by that key. Then, I selected the street name where the type is equal to "through" and again where type is equal to "cross". But, I get an error, like this: ----begin quote---- CWBDB0099 - No more data is available for the stream fetch request SQL0212 - Duplicate table designator CMSLOCQ not valid. Cause . . . . . : More than one table in a FROM clause of a subselect has a table designator with the name CMSLOCQ. If a correlation name is specified, the correlation name is the table designator. If one is not specified, the table name or view name is the table designator. If SQL naming is specified, the table name consists of the implicit or explicit collection name followed by the actual table name. If system naming is specified, the table name itself is used without a qualifier as the table designator. The table designator must be unique on each level of a subselect. Recovery . . . : Make certain there is a unique table designator for every table in a FROM clause for the same level of a subselect. Since collection-name/table-name cannot be used to qualify a column, the table name must be unique or a correlation name must be specified. Correct any errors and try the request again. -----end quote----- Any suggestions? Thanks! -- Sent by cwh from pobox part from com This is a spam protected message. Please answer with reference header. Posted via http://www.usenet-replayer.com/cgi/content/new Top AS400 to PC transfer - error when trying to query same table twice by AikiBC » Fri, 27 Jul 2001 15:27:10 You could create a view on the 400 that joins the two tables and then use the 400 to PC data transfer to pull down the data from the view. That should get you what you are after. That way, you are only using one "table" (file) on the 400. Just a thought, Brian Quote:> I'm getting an error when I try to use the AS400 to PC data transfer and query the same table twice. Here's what I'm trying to do: Quote:> Select the street name twice from the same table, once for the "through > street" and again for the "cross street" at an accident. In other > words, get "Pine at Elm".