Showing posts with label bug. Show all posts
Showing posts with label bug. Show all posts

Tuesday, March 27, 2012

Foreach Loop Problem (Bug?)

We discovered that the Foreach loop isn't recalculating the number of files found upon each new loop iteration, so if any new files are placed into the receive directory during the looping, they are not detected/processed. is this a bug or product intention?

Jason,

I would guess that this is by design - and rightly so in my humble opinion.

-Jamie

|||Well comes problems when you have a listener that triggers a foreach loop, but when loop completes and goes back to listening, the files that were placed on directory during loop iteration just sit there until a new file or change occurs.|||

I am pretty sure the documentation does mention this.

You could wrap the for each in another loops until no files are processed.

Monday, March 26, 2012

ForEach File Enumerator extension bug?

I set up a basic ForEach enumerator loop and specified files of type *.sql.

In the directory, I had some files I needed to keep but didn't want the package to touch, so I changed the extension to *.sqlo. Much to my dismay, the ForEach loop picked up those files. (Though it did skip the *.xml and *.bat and a few other types...)

Sounds like a bug to me.

That is expected wildcard behaviour. At least, it is what I would expect. To verify I wasn't 'shrooming, I checked out: http://msdn2.microsoft.com/en-us/library/wz42302f.aspx where I found this to put my mind at ease ...

Note

When using the asterisk wildcard character in a searchPattern, such as "*.txt", the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A searchPattern with a file extension of exactly three characters returns files having an extension of three or more characters, where the first three characters match the file extension specified in the searchPattern. A searchPattern with a file extension of one, two, or more than three characters returns only files having extensions of exactly that length that match the file extension specified in the searchPattern. When using the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, "file1.txt" and "file1.txtother", in a directory, a search pattern of "file?.txt" returns just the first file, while a search pattern of "file*.txt" returns both files.

Donald

|||

I believe you (after looking at that link). But that is just bizarre and, to me, nonsensical. Especially if one continues to read. This *only* applies to a 3-character extension search pattern - nothing else.

Why oh why would they do such a stupid thing?

This means that there is direct no way to specify give me only the three character file extension files that I've told you to give me.

Were they shrooming when they came up with this?

If I wanted the other extensions I'd ask for "*.txt*".

Monday, March 12, 2012

FOR XML RAW & Null Characters Bug

Just curious if anyone else has seen this issue:
We had a situation where the XML being retrieved from an XML Explicit query
was malformed. After looking at the resulting XML from the query being ran
with different sets of paramaters we were able to identify that the building
of the XML was stopping on the same value. Looking further we noticed this
field had a null character (ASCII code of 0).
Here's a simple example showing the issue:
declare @.var varchar(100)
set @.var='Josh' + CHAR(0)
select @.var AS Col
for XML RAW
this results in <row Col="Josh
I couldn't find if this was a documented bug or expected behavior? Does
anyone know of any articles that describe how the null character is handled
in SQL?
Thanks
JoshOn Mon, 30 Jan 2006 13:05:31 -0800, joshb wrote:

>Just curious if anyone else has seen this issue:
>We had a situation where the XML being retrieved from an XML Explicit query
>was malformed. After looking at the resulting XML from the query being ran
>with different sets of paramaters we were able to identify that the buildin
g
>of the XML was stopping on the same value. Looking further we noticed this
>field had a null character (ASCII code of 0).
>Here's a simple example showing the issue:
>declare @.var varchar(100)
>set @.var='Josh' + CHAR(0)
>select @.var AS Col
>for XML RAW
>this results in <row Col="Josh
>I couldn't find if this was a documented bug or expected behavior? Does
>anyone know of any articles that describe how the null character is handled
>in SQL?
Hi Josh,
The problem is that ASCII 0 is used as a string delimiter in many
languages. So the low-level code that sends the results to the screen
sees the ASCII 0 and thinks it's the end of the string.
Try running your code from another client (e.g. osql).
Hugo Kornelis, SQL Server MVP|||Hi, Josh
The problem is fixed in SQL Server 2005, where your example returns
this (in Management Studio or in Query Analyzer):
<row Col="Josh�"/>
However, Management Studio warns that the character with the code 0x0
is illegal in XML documents.
Razvan