"Набор другого материала", все агрегируется? Я принимаю поэтому, так как Ваш GROUP BY только имеет t3.id. Если это так, тогда это должно работать:
SELECT
COUNT(DISTINCT t3.id)
FROM...
другая опция, конечно:
SELECT
COUNT(*)
FROM
(
<Your query here>
) AS SQ
я не использую MySQL, таким образом, я не знаю, будут ли эти запросы работать там или нет.
Это связано с тем, что один из объектов ContactInfo
является прокси-сервером веб-службы и находится в другом пространстве имен.
Это известная проблема с веб-службами в стиле asmx . В прошлом я реализовал автоматическое мелкое копирование, чтобы обойти это ( вот как , хотя если бы я делал это снова, я бы, вероятно, вместо этого посмотрел на AutoMapper ).
Например, если у вас есть сборка со следующим классом:
MyProject.ContactInfo
, и вы возвращаете ее экземпляр из веб-метода:
public class DoSomethingService : System.Web.Services.WebService
{
public MyProject.ContactInfo GetContactInfo(int id)
{
// Code here...
}
}
Затем, когда вы добавляете веб-ссылку в свой клиентский проект, вы фактически получаете следующее:
MyClientProject.DoSomethingService.ContactInfo
Это означает, что если в своем клиентском приложении вы вызываете веб-службу для получения ContactInfo
, у вас возникает такая ситуация:
namespace MyClientProject
{
public class MyClientClass
{
public void AskWebServiceForContactInfo()
{
using (var service = new DoSomethingService())
{
MyClientProject.DoSomethingService.ContactInfo contactInfo = service.GetContactInfo(1);
// ERROR: You can't cast this:
MyProject.ContactInfo localContactInfo = contactInfo;
}
}
}
}
Это последняя строка, в которой я использую свой ShallowCopy
класс:
Как вы ссылаетесь на класс в своем проекте веб-службы, а также в потребительском проекте? Если вы просто использовали ссылку на файл, это вполне могло бы объяснить причину ошибки. Способ сериализации работает для .NET (веб-служб или как-то иначе, я полагаю) заключается в использовании отражения для загрузки / выгрузки данных объекта. Если файлы просто связаны, то они на самом деле компилируются в разные типы в разных сборках, что объясняет, почему у вас одно и то же имя, но нельзя выполнять приведение между ними. Я рекомендую создать «Базовую» библиотеку, на которую ссылаются как веб-сервис, так и потребительский проект, и содержащий класс ContactInfo
, который вы используете везде.
Как было предложено в нескольких других ответах, это связано с тем, что .NET видит их как два разных класса. Я лично рекомендую использовать что-то вроде AutoMapper . Я пользуюсь им, и это кажется довольно крутым. Вы можете скопировать свои объекты в 1-2 строчки кода.
Mapper.CreateMap<SourceClass, DestinationClass>();
destinationInstance = Mapper.Map<SourceClass, DestinationClass>(sourceInstance);
Похоже, у вас есть два разных класса на обоих концах. В вашем приложении есть класс ContactInfo, а в вашем веб-сервисе также есть класс ContactInfo. Оба являются двумя совершенно разными классами. Один из способов - использовать класс WebService на своей стороне. Если вы используете ContactInfo внутри своего веб-сервиса, он будет сериализован и будет доступен для использования на стороне клиента.
Это не проблема - это особенность.
Это два независимых класса. Сравните два и обратите внимание, что прокси-класс не имеет конструкторов, методов, индексаторов или другого поведения из исходного класса. Это точно то же самое, что произошло бы, если бы вы использовали службу ASMX с программой Java.
Вообще-то, это не ошибка. Это проблема со сменой версии вашего собственного проекта! Потому что при окончательной компиляции вы не используете оригинальные импортированные ссылки!
Например, я делал чат-сервер, клиент. Я использовал структуру пакетов для передачи данных по клиентскому проекту. Затем импортировала ту же самую ссылку на серверный проект.
При компиляции Пакетный пакет = (Packet)binaryFormatter.Deserialize(stream);
я получил такую же ошибку. Потому что реально работающая ссылка на серверный проект сейчас не является ссылкой на клиентский проект! Потому что я перестроил проект клиента много раз после!
При кастинге
всегда новый объект должен быть более новой или той же версией, что и старый!
Итак, я собрал отдельный проект для создания DLL для класса Packet и импортировал файл DLL в оба проекта.
Если я сделал какое-либо изменение в классе Packet, я должен импортировать ссылку как на клиента, так и на сервер снова.
Тогда при кастинге не будет сделано вышеуказанное исключение!