News

Statistics

Locations of visitors to this page

Personal


I discovered a nasty bug in the way Sybase Iq last_value over partition works. More precisely it returns random values. On the other hand first_value is working fine so for now I am using that one instead, with reverse ordering in partitions. But it makes my queries a little harder to understand.

Try this eg:

Let's say we have table TestLastValueTable

TableId     RequestId       Sender        MessageNumber      Location
1                    1                      alan                           2                     London
2                    1                      mary                          3                     Paris
3                    1                      mike                          1                     Sevilla
4                    2                      gaga                         2                      Paris
5                    2                      gugu                         3                      Sevilla

When using the following query:

Select Id, requestId , last_value(sender) over (partition by requestId order by messageNum desc)  as lastRequestSender ,
    first_value(location) over (partition by requestId order by messageNum desc)  as firstRequestLocation
From TestLastValueTable
order by Id


I expected the outcome to be

Id,    requestId,    lastRequestSender,    firstRequestLocation
1,          1,                   'mike',                             'Paris'
2,          1,                   'mike',                             'Paris'
3,          1,                   'mike',                             'Paris'
4,          2,                   'gaga',                             'Bucharest'
5,          2,                   'gaga',                             'Bucharest'

And it actually is :

Id,    requestId,    lastRequestSender,    firstRequestLocation
1,           1,                  'alan',                                   'Paris'
2,           1,                  'mary',                                  'Paris'
3,           1,                  'mike',                                  'Paris'
4,          2,                   'gaga',                                  'Bucharest'
5,          2,                   'gugu',                                  'Bucharest'
 

UPDATE: This bug is related to the partition, changing the partition to being specified by "rows between unbounded preceding and unbounded following" (which should not make any difference) , makes last_value to return the correct value:

Select Id, requestId , last_value(sender) over (partition by requestId order by messageNum desc rows between unbounded preceding and unbounded following)  as lastRequestSender ,
    first_value(location) over (partition by requestId order by messageNum desc)  as firstRequestLocation
From TestLastValueTable
order by Id

 

 

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati


I was trying to update a service reference in a Silverlight project and  I got :  Error HRESULT E_FAIL has been returned from a call to a COM component.

Problem was that ServiceReferences.ClientConfig file being actually a common file shared between 3 projects, I extracted it outside and referenced it from a common project as a link to the file. When the reference (creation or update) wizard is trying to update this file, this "very descriptive and intuitive" error shows up.

So, when getting this error and in doubt check that configuration file is writable from your location.

Good luck!

 

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati


First I downloaded Statlght and copied the binaries here: C:\Program Files\StatLight.v1.3, I tests that Statlight is working fine on the build machine and then I added a new step in my build in order to run the tests

There is quite a lot of stuff on creating the TeamCity step, but every single post I found was missing some double quotes here and there :) so this might be saving you some time.

Here is the configuration that is working for me:

( Build Step 1 compiles and builds the project)

Build Step 2 : Command line

Runner type: Command Line

Working Directory : empty

Run: Executable with parametres

Command executable: "C:\Program Files\StatLight.v1.3\StatLight.exe"

Command parameters : -x="C:\Source\trunk\<SolutionName><ProjectName>.Tests\Bin\Release\<projectName>.Tests.xap" --teamcity

Report type: Do not process

The output of this step in the project settings page is as it follow:

Step 2: Command Line (Simple command execution)
Working directory: same as checkout directory
Command executable: "C:\Program Files\StatLight.v1.3\StatLight.exe"
Command parameters: -x="C:\Source\trunk\<SolutionName><ProjectName>.Tests\Bin\Release\<projectName>.Tests.xap" --teamcity
XML report processing: disabled

 

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati


InvalidOperationException: Cross-thread operation not valid: Control 'progressBar' accessed from a thread other than the thread it was created ...

Now this is not a nice way to start a day! not even if it's a Monday!

So you have seen this and already thought, come on, this is an old one, just ask whether InvokeRequired before calling the method in the control, something like this:

if (progressBar.InvokeRequired) {

          progressBar.Invoke  ( new MethodInvoker( delegate {  progressBar.Value = 50;    }) )

}else

     progressBar.Value = 50;   

Unfortunately this was not working the way I would have expected, I got this error, debugged and though in debugging the InvokeRequired had become true , the error was thrown on the branch that did not required Invoke.

So there was a scenario where InvokeRequired returned false and still accessing the control was not on the right thread ...

Problem was that I kept showing and hiding the little form showing the progressbar. The progressbar was updating on an event  , ProgressChanged and I could not guarantee the little form was loaded by the time the event was thrown.

So , spotted the problem, if none of the parents of the control you try to modify is created at the time of the method invoking, the InvokeRequired returns true! That causes your code to execute on the woring thread. Of course, updating UI before the win dow was created is not a legitimate action either, still I would have expected a different error.

MSDN:

"If the control's handle does not yet exist, InvokeRequired searches up the control's parent chain until it finds a control or form that does have a window handle. If no appropriate handle can be found, the InvokeRequired method returns false.

This means that InvokeRequired can return false if Invoke is not required (the call occurs on the same thread), or if the control was created on a different thread but the control's handle has not yet been created."

Have  a look at InvokeRequired's implementation:

public bool InvokeRequired
{
    get
    {
        HandleRef hWnd;
        int lpdwProcessId;
        if (this.IsHandleCreated)
        {
            hWnd = new HandleRef(this, this.Handle);
        }
        else
        {
            Control wrapper = this.FindMarshallingControl();
            if (!wrapper.IsHandleCreated)
            {
                return false; // <==========
            }
            hWnd = new HandleRef(wrapper, wrapper.Handle);
        }
        int windowThreadProcessId = SafeNativeMethods.GetWindowThreadProcessId(hWnd, out lpdwProcessId);
        int currentThreadId = SafeNativeMethods.GetCurrentThreadId();
        return (windowThreadProcessId != currentThreadId);
    }
}

Here 's a good article about this and a workaround http://www.ikriv.com/en/prog/info/dotnet/MysteriousHang.html

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati


Given a SqlConnection, a SqlCommand if you need to execute a stored procedure it is enough to specify the stored procedure name as the CommandText and it will work.

Now the surprise is that if you also add parametres, you get this creepy error: SqlException: Line 1 incorrect syntax near [storedProcedureName].

The quick fix is to specify the CommandType to be StoredProcedure.

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati