Linq To SQL - podgląd zapytania

Witam,

używam Linq To SQL do połączenia ze zdalną bazą. Piszę program do obsługi bazy Prestashop.
Ogólnie wszystko jest w porządku, ale mam problem z zapytaniami w kierunku jednej z tabel bazy danych (na wszystkich innych zapytania wykonują się dobrze).
Dostaję typowy alert:
Something is wrong in your syntax obok 'condition, customizable, date_add, date_upd, depth, ean13, ecotax, height, id_ca' w linii 1

Podejrzewam, że pytanie źle się generuje, ale szczerze mówiąc nie mam pojęcia jak podejrzeć kompletne zapytanie przed jego wysłaniem do bazy - i tutaj moja prośba o pomoc, czy da się w ogóle to zapytanie podejrzeć?

Czy zapytania w Linq to SQL są ograniczone długością? Jest to druga kwestia, która podejrzewam, ponieważ tabela zawiera 46 kolumn co przy zapytaniu typu insert może wygenerować dosyć długie zapytanie.

Dodam, że przez PHPmyAdmin nie ma najmniejszego problemu z zapytaniami.
Ważne też jest to, że używam Linq to SQL na bazie MySQL dzięki DBlinq - automatycznie generowane klasy dla bazy MySQL. Metoda pozwala na operacje na bazach MySQL jakby były bazami SQL.

Dlatego podejrzewam, że w którymś miejscu zapytania jest jakiś głupi błąd, ale nie potrafię wyświetlić zapytania żeby to sprawdzić

jakbyś chociaż pokazał jakiś fragment kodu...

Azarien napisał(a)

jakbyś chociaż pokazał jakiś fragment kodu...

Nie wklejałem wcześniej, ponieważ uważam, że niewiele to pomoże jeśli ktoś nie zna struktury bazy:

 private void button1_Click(object sender, EventArgs e)
        {
            HalPOrPRestA conn = new HalPOrPRestA(new MySqlConnection("Database=***;Data Source=***;User Id=***;Password=***"));            
            
            conn.PsProduct.InsertOnSubmit(new PsProduct { Condition=PsProduct.ConditionType.used, IDSupplier = 10, IDTaxRulesGroup = 1, DateAdd = DateTime.Now, DateUpd = DateTime.Now });            

            conn.SubmitChanges(); 

HalPOrPRestA to klasa automatycznie wygenerowana przez DbLinq. Opisana wyżej metoda działa bez problemu na wszystkich tabelach za wyjątkiem Ps_product.
Załączam jeszcze strukturę tabeli PS_product:

 DROP TABLE IF EXISTS `ps_product`;
CREATE TABLE `ps_product` (
  `id_product` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `id_supplier` int(10) unsigned DEFAULT NULL,
  `id_manufacturer` int(10) unsigned DEFAULT NULL,
  `id_tax_rules_group` int(10) unsigned NOT NULL,
  `id_category_default` int(10) unsigned DEFAULT NULL,
  `id_color_default` int(10) unsigned DEFAULT NULL,
  `on_sale` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `online_only` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `ean13` varchar(13) DEFAULT NULL,
  `upc` varchar(12) DEFAULT NULL,
  `ecotax` decimal(17,6) NOT NULL DEFAULT '0.000000',
  `quantity` int(10) NOT NULL DEFAULT '0',
  `minimal_quantity` int(10) unsigned NOT NULL DEFAULT '1',
  `price` decimal(20,6) NOT NULL DEFAULT '0.000000',
  `wholesale_price` decimal(20,6) NOT NULL DEFAULT '0.000000',
  `unity` varchar(255) DEFAULT NULL,
  `unit_price_ratio` decimal(20,6) NOT NULL DEFAULT '0.000000',
  `additional_shipping_cost` decimal(20,2) NOT NULL DEFAULT '0.00',
  `reference` varchar(32) DEFAULT NULL,
  `supplier_reference` varchar(32) DEFAULT NULL,
  `location` varchar(64) DEFAULT NULL,
  `width` float NOT NULL DEFAULT '0',
  `height` float NOT NULL DEFAULT '0',
  `depth` float NOT NULL DEFAULT '0',
  `weight` float NOT NULL DEFAULT '0',
  `out_of_stock` int(10) unsigned NOT NULL DEFAULT '2',
  `quantity_discount` tinyint(1) DEFAULT '0',
  `customizable` tinyint(2) NOT NULL DEFAULT '0',
  `uploadable_files` tinyint(4) NOT NULL DEFAULT '0',
  `text_fields` tinyint(4) NOT NULL DEFAULT '0',
  `active` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `available_for_order` tinyint(1) NOT NULL DEFAULT '1',
  `condition` enum('new','used','refurbished') NOT NULL DEFAULT 'new',
  `show_price` tinyint(1) NOT NULL DEFAULT '1',
  `indexed` tinyint(1) NOT NULL DEFAULT '0',
  `cache_is_pack` tinyint(1) NOT NULL DEFAULT '0',
  `cache_has_attachments` tinyint(1) NOT NULL DEFAULT '0',
  `cache_default_attribute` int(10) unsigned DEFAULT NULL,
  `date_add` datetime NOT NULL,
  `date_upd` datetime NOT NULL,
  PRIMARY KEY (`id_product`),
  KEY `product_supplier` (`id_supplier`),
  KEY `product_manufacturer` (`id_manufacturer`),
  KEY `id_category_default` (`id_category_default`),
  KEY `id_color_default` (`id_color_default`),
  KEY `date_add` (`date_add`)
) ENGINE=MyISAM AUTO_INCREMENT=10 DEFAULT CHARSET=utf8;

#
# Dumping data for table ps_product
#

LOCK TABLES `ps_product` WRITE;
/*!40000 ALTER TABLE `ps_product` DISABLE KEYS */;
INSERT INTO `ps_product` VALUES (7,0,0,1,1,0,0,0,'',NULL,0,180,1,241.638796,200,NULL,0,0,'',NULL,NULL,0,0,0,0,2,0,0,0,0,1,1,'new',1,1,0,0,NULL,'2011-10-21 14:49:25','2011-10-21 14:49:25');
INSERT INTO `ps_product` VALUES (9,2,2,1,1,0,0,1,'',NULL,0,1,1,124.58194,0,NULL,0,0,'',NULL,NULL,0,0,0,0,2,0,0,0,0,1,1,'new',1,1,0,0,NULL,'2011-10-21 14:49:25','2011-10-21 14:49:25');
/*!40000 ALTER TABLE `ps_product` ENABLE KEYS */;
UNLOCK TABLES;

Oczywiście, nie chodzi mi o to, żeby ktoś rozwiązywał za mnie problem - ale liczę na podpowiedzi gdzie mogę szukać rozwiązania.

podbijam jeszcze raz, docenię KAŻDY pomysł

Problem rozwiązany:

jedno z pól w bazie nazwane jest 'condition' - a jest to jednocześnie słowo kluczowe języka MySQL, dlatego był problem z dodaniem produktu.
Nie wiem jeszcze jak w kodzie Presty jest to rozwiązane, ale podejrzewam, że jest to pewnego rodzaju zabezpieczenie przed zdalną administracją Presty.

Do zamknięcia, aczkolwiek problem jest ciekawy.
Pozdrawiam

Czy połączenie jest szyfrowane? Jeżeli nie, może najprostszym sposobem na podejrzenie zapytania będzie użycie sniffera, np. Wiresharka

Sarrus, bardzo dobry pomysł :) skorzystałbym z niego, ale już na szczęście nie muszę - tak jak napisałem post wyżej, udało się rozwiązać problem