Drag nodes using draggableviews order in second sort of criteria.

The current dev version may solve this problem. Unfortunately your draggableviews must be reconfigured because the configuration page changed a little bit.
Look at #311264: why one weight field per level ? for more details.

No, what I said related to the number of hierarchy levels (in the same view). Don't get confused by this. It simply means that a parent can have a parent that can have a parent...and so on, without any restrictions.

If you want different weights in different views you should use the Native Handler in combination with "Draggableviews: Order" Field and "Draggableviews: Parent" Field. These fields ("Draggableviews: Order", "Draggableviews: Parent") are unique for each view (but not unique for different displays of the same view!).
YOU MUST CLEAR THE VIEWS CACHE before using the current dev!

Native Handler is easier to use and it works much more efficient than CCK Handler because of the CCK overhead.

I think I still didn't understand what you mean. I'll summarize this issue with an example and you'll tell me if I'm wrong:

Column1: A fixed value (The value that should be your first sort-criteria).
Column2: The order value applied by draggableviews.
Look at the following table:

(Column1 dominates)
1 | 3
1 | 4
1 | 5
1 | 6
2 | 1
2 | 2
2 | 7

The column1-values of the first 4 rows are equal. So column2 becomes relevant.
The last 3 rows are always on the bottom, independent of the column2-value. Thus The fifth row (2|1) will never move to the first place, even if draggableviews wants this.
Draggableviews would try to repair the structure above; but without any effect. The structure will always stay broken.

But if all rows are equal on the first level (column1) then draggableviews will work. I suppose this is what you need. Look at the following example:

(Column1 doesn't have any effect)
1 | 1
1 | 2
1 | 3
1 | 4
1 | 5
1 | 6
1 | 7

But this can be achieved by using a simple filter. Just filter by column1=1.

Tell me, did I get the point?
greetings,
sevi

Okey you're right, it would "work". When repairing the view the outputted nodes will be renumbering in ascending order. The example explains:

With javascript you can drag the nodes e.g. to look like this:

2 | ?
2 | ?
1 | ?
1 | ?
1 | ?
1 | ?
2 | ?

After saving the view the submitted nodes will be numbered in ascending order and look like this:

2 | 1
2 | 2
1 | 3
1 | 4
1 | 5
1 | 6
2 | 7

Then the view gets loaded and the results will be ordered by column1, column2 and the structure would look like this:

1 | 3
1 | 4
1 | 5
1 | 6
2 | 1
2 | 2
2 | 7

This structure is broken. The structure will be repaired and looks like this: (repair means: simply assign ascending numbers to the actual output)

1 | 1
1 | 2
1 | 3
1 | 4
2 | 5
2 | 6
2 | 7
A message "The structure has been repaired successfully" will be displayed (did you see this message?).

Thats the progress after saving such a view. You'll understand that this is not how it should be done :) I used quotes for the word "work" in the beginning because of the induced complications.

I suppose you found the answer to your last question in this post.
Greetings,
sevi

First I want to say that "Draggableviews: Order" fields and "CCK" fields are equal in this context. I still recommend the usage of "Draggableviews: Order" field in combination with "Native" handler, yes.

No solutions to add first votingapi values order and second draggableviews order?

The problem is, that my validation check doesn't allow to have your special sort criterias defined. I don't want to change this validation check because of this special issue. But you can bypass this problem by implementing hook_views_pre_build() in a custom module. There you can change the views sort criteria programmatically every time the view gets loaded. The implementation could look similar to the following piece of code (with dummy values):

function yourmodule_views_pre_build(&$view) {
  if (!$view->vid == 20) return;

  $handler->override_option('sorts', array(
    'votingapi_order' => array(
      'order' => 'ASC',
      'id' => 'votingapi_order',
      'table' => 'voting_api_table',
      'field' => 'votingapi_order',
      'override' => array(
        'button' => 'Override',
      ),
      'relationship' => 'none',
    ),
  ));
}

I'm not sure at all if this code works. You should ask someone who knows more about manipulating views.

and work perfectly?

If the user doesn't drag a node with votingapi value 2 above a node with votingapi value 1 (see last example) the structure actually wouldn't be broken. Yes, it would work perfectly in the majority of cases.

Greetings,
sevi

Won't fix because this issue would break the fundamental concepts of tabledrag js and draggableviews validation checks.

Conclusion: The DraggableViews Order value must be the first sort criteria at all (actually this should be the only sort criteria because all additional sort criteria wouldn't have any effect). However, if you want to display nodes in a different order you'll have to assign the DraggableViews Order values appropriate (however you accomplish this).