Blad: 'Multiple -step opperation generated' + ADOTable

[miko]

Witam,
mam kolejny problem z operacja na tabeli (MS SQL Server), uzywam komponentów ADO.
Wiec, mam prosta tabele, jedno z pól jest zdefiniowane jako Primary Key, typu int, autoincrement (Is Identity = Yes). Reszta to jakies pola tekstowe, jedno memo, jedno datetime. W programie uzywam komonentu TADOTable. Przy próbie zapisu czegokolwiek do tabeli program sie wysypuje z komunikatem:
'Multiple -step opperation generated. Check each status value.'
Szczerze mówiac pierwszy raz to widze. Czy ktos sie moze z tym juz spotkal?

[Cyfrowy Baron]

Po jakiej zmianie w kodzie zaczął pojawiać się ten komunikat?

[miko]

Przy próbie zapisu:

Kod: Zaznacz cały

TADOTable1->Post();


Bez znaczenia czy jest to edycja czy dodanie nowego wiersza do tabeli. Najpierw próbowalem oczywiscie dodac wiersz, potem dodalem go bezposrednio do tabeli (SQL Server Management Studio) i chcialem zedytowac, blad pojawia sie przy kazdej próbie wywolania

Kod: Zaznacz cały

TADOTable1->Post();


[Cyfrowy Baron]

Sprawdziłeś, czy błąd występuje również w sytuacji gdy Is Identity ustawisz na No?

Gdy pytałem o zmiany w kodzie, nie chodziło mi o to co robisz. Zakładam, że wcześniej kod działał prawidłowo, potem dokonałeś zmian w kodzie:

mam prosta tabele, jedno z pól jest zdefiniowane jako Primary Key, typu int, autoincrement (Is Identity = Yes).

Czy błąd występuje od czasu dodania tego pola? Czy bez tego pola kod działa prawidłowo?

[miko]

Wczesniej w ogóle nie mialem tej tabeli w programie. Jest to program bazodanowy przechowujacy informacje o skargach i zazaleniach klientów, zawiera jedna glowna tabele z podstawowymi informacjami jak nr kolejny, data, klient, produkt, partia itd. Do tego istnieje kilka pomniejszych tabel przechowujacych inne informacje, jak np. tabela z notatkami, posiadajaca nr zazalenia, imie nazwisko osoby dodajacej komentarz i tresc - ludzie dodaja tam rózne wpisy podczas prowadzenia sprawy, dochodzenia gdzie na linii produkcji powstalo zaniedbanie. Takich tabel jest jeszcze kilka. Wsyztskie tworze tym samym schematem, wszystkie posiadaja klucz Primary Key który jest definiowany jako Autoincrement (czyli w przypadku SQL Servera nalezy ustawic wlasciwosc Is Identity na 'Yes'), - to pomaga w tworzeniu relacji pomiedzy tabela glowna i pomniejszymi, oraz filtrowaniu. Dodam, ze wszystkie dzialaja bez zarzutu. Na pewnym etapie pisania programu pojawila sie potrzeba stworzenia nowej 'sekcji' o nazwie 'dochodzenie', gdzie wyznacza sie osobe odpowiedzialna za dokladne przeanalizowanie wszystkich okolicznosci zaistnialych w procesie tworzenia danej partii produktu, przegladu maszyn itp. Na tym etapie tworzone sa cykliczne raporty, powinny one byc zapisywane do tabeli, polaczone z tabela glowna.
Po utworzeniu odpowiedniej tabeli, dodalem kompnent do w programie i odwolalem sie do niego po kliknieciu na odpowiedzni przycisk:

Kod: Zaznacz cały

ADOdane->Tinvest->Insert();
(...)
ADOdane->Tinvest->Post();


wtedy pojawil sie wspomniany blad.
Dodam moze tylko, ze po samym wywolaniu

Kod: Zaznacz cały

ADOdane->Tinvest->Insert();

nic sie jeszcze nie dzieje, dopiero gdy program próbuje wykonac

Kod: Zaznacz cały

ADOdane->Tinvest->Post();

program staje.

Nie próbowalem szczerze mówiac wylaczyc funkcji autoinkrementacji, bo jej potrzebuje, poza tym wszystkie inne tabele tez maja zdefiniowane takie wlasnie pole ID i nie ma z tym problemu, ale sprawdze równiez i to.

[miko]

Tak jak myslalem, pozbycie sie autoinkrementacji nic nie zmienilo dalej pojawia sie ten sam blad.

[miko]

NO I MAM !!!!
Rozwiazanie bylo banalne. Do pola tekstowego vchar(15) zapisywana byla wartosc dluzsza niz 15 znaków. Moje male niedopatrzenie - program pobieral wartosc razem ze spacjami po zakonczeniu stringa .Trim() zalatwilo sprawe
Ale dzieki tak czy inaczej

[Cyfrowy Baron]

Z danych które tutaj podałeś nigdy nie udałoby się wyciągnąć takiego wniosku.

[miko]

dlaczego nie? Cytuje zródlo, w którym znalazlem odpowiedz:

Without looking at your code I can tell you that you are getting this error because you are trying to put a string into a VARCHAR field that is too long. So, for example you are trying to put a 60 char string into a VARCHAR(50) field.

adres:
http://forums.digitalpoint.com/showthread.php?t=59813

Mysle, ze teraz jak spotkam sie z takim komunikatem juz bede wiedziec co on oznacza (przyznam, ze malo jest 'domyslny), po prostu wczesniej sie z nim nie spotkalem. Nie wiedzialem tez, ze w pewnym momencie kompilator 'dokleja' spacje po zakonczeniu stringa robiac z "1_2011" string: "1_2011____________"; Ale ciezko bylo na to wpasc - pomysl podsunal mi cytowany post i po prostu za pomoca debugera sprawdzalem wartosc po wartosci jaka zapisuje mi program do tabeli - wtedy sie udalo Grunt, ze dziala Moze komus sie ten post jeszcze przyda - pozdrawiam.

[Cyfrowy Baron]

dlaczego nie?

Dlatego, że z komunikatu o błędzie wcale to nie wynika. Zapisujesz więcej niż zmienna może pomieścić. Ten problem nie wiąże się bezpośrednio z bazą danych, lecz z pojemnością zmiennej typu char.

Do pola tekstowego vchar(15) zapisywana byla wartosc dluzsza niz 15 znaków.

czyli char zmienna[15] nie pomieści więcej znaków.

Nie wiedzialem tez, ze w pewnym momencie kompilator 'dokleja' spacje po zakonczeniu stringa robiac z "1_2011" string:

Kompilator niczego nie dokleja. Kompilator tłumaczy kod z języka programowania, na kod maszynowy.

To rozwiązanie z Trim() sugeruje, że wciąż masz coś nie tak z tą bazą danych. Póki co działa, ale w przyszłości problem może powrócić. To jednak tylko może przeczucie, wszak kodu nie widzę...

[miko]

Kompilator niczego nie dokleja. Kompilator tłumaczy kod z języka programowania, na kod maszynowy.

Oczywiscie wiem o tym, to byla przenosnia - taki skrót myslowy. To tlumaczenie na kod maszynowy odbywalo sie przy próbie zczytania wartosci komponentu Edit firmy TMS, który mial wpisana maksymalna dlugosc pola 30 znaków.
Podczas wykonywania operacji

Kod: Zaznacz cały

ADOdane->TinvestCASE_UNQ->AsString=AdvEdit1->Text;

nie widac bylo golym okiem, ze AdvEdit1->Text zamiast "1_2011" ma wartosc "1_2011+24 spacje nastepujace po niej),

Ten problem nie wiąże się bezpośrednio z bazą danych, lecz z pojemnością zmiennej typu char.

vchar(15) to pole w konkretnej tabeli a nie

char zmienna[15]

To nie to samo. Przy zdefiniowaniu kolumny w bazie jako char(15) kompilator, przy próbie zapisania to takiego pola w bazie zmiennej dluzszej niz 15 znaków po prostu zapisze to co sie zmiesci a reszte obetnie (mówie oczywiscie o zapisaniu wartosci bezposrednio do pola w bazie a nie do zmiennej char[15]), wczesniej firma wymagala stosowanie komponentów BDE w naszych programach (glownie chodzilo o kompatybilnosc, zgodnosc ze starymi wersjami i tym co umieli starsi programisci oraz po prostu zyczenie szefa), ale zaczelismu stopniowo przechodzic na ADO. ten probelm nie istniaj w przypadku BDE, gdyz one nie widza pól typu nchar i trzeba bylo wszystkie pola w bazie definiowac jako char. Ale mniejsza o to. Wczesniej nikt sie z takim bledem nie spotkal, wiec trudno bylo odgadnac.
Wlasnie w tym, ze z komunikatu o błędzie zbyt wiele nie wynika tkwila cala trudnosc, chodzilo mi o to, ze pewnie na przyszlosc juz bede wiedziec, ze taki wlasnie komunikat sugeruje nieprawidlowosci zwiazane z dlugoscia pola w bazie i wielkoscia zmiennej i moze komus tez sie ta wiedza przyda.