hello diez, other friends, thanks a lot for your consideration.
On 11/13/2011 08:11 PM, Diez B. Roggisch wrote: > > Is it possible that you have declared models in different sessions? This has > cause me similar issues > before. It means essentially that you have two connections open, for each > session. And commits over the middleware only affect one of them. > i have, deep in my heart, a similar suspicion, but no idea of a way to check it. indeed, the same db user is making other connections as well from another site program. but these kept occurring when i run ddl and dml successfully through sa, even with the same model, but not through tg controllers. moreover, my failing code is successfully doing a select before it attempts to update and fails. before trying to update, i tried some ddl without select, but with the same failure. any idea of a way i could check your suspicion? thanks in advance, alex > Diez > > On Nov 13, 2011, at 5:50 PM, alex bodnaru wrote: > >> >> hello julien, other friends, >> >> no joy yet. >> >> On 11/11/2011 08:54 AM, alex bodnaru wrote: >>> >>> hello julien, >>> >>> that seems to be the representation of a smallmoney field. i'm not filling >>> up >>> the data manually, but it's a row from a query returned by sa on a >>> similarily >>> formatted table. >>> >>> about the failure issue - i'm going to first reinstall on a linux host and >>> maybe >>> use one of your other suggestions. >> i didn't have the linux infrastructure ready. >> but looking at the system again, my other ddl and dml attempts succeeded >> through >> the same mssql+pyodbc connection, and i committed with either >> transaction.commit() in bootstrap.py or dbsession.commit() outside >> turbogears. >> >> conversely, ddl and dml statemnts get to the server (it returns eventual >> syntax >> errors), just don't take effect (are rolledback somewhere in tg, after my >> controller is being invoked). >> how could i try to debug the tg calling my controller? >>> >>> best regards, >>> alex >>> >>> On 11/10/2011 01:47 PM, Julien Tayon wrote: >>>> Is it normal that cost price is a decimal when all other prices are float ? >>>> Is your python model consistent with your db ? >>>> Have you replayed your Sql statement with the value dumped in the debug, >>>> and are >>>> you sure you dont violate any constraints ? >>>> >>>> >>>> >>>> Le 9 nov. 2011 ŕ 18:41, alex bodnaru <[email protected]> a écrit : >>>> >>>>> >>>>> hey julien, >>>>> >>>>> still doesn't work but now even update statements fail to take effect. >>>>> 19:34:00,966 INFO [sqlalchemy.engine.base.Engine] update >>>>> tblitemcategories set >>>>> Unitlimit=?, Step=?, SaleUnit=?, Price=?, VipPrice=?, costPrice=?, >>>>> costPriceCurrency=?, isOfferItem=?, OfferItemPrice=?, Vip=?, isOnSale=?, >>>>> DeliveryDaysAdd=?, is_heavy=?, no_special_price=?, SalePrice=?, >>>>> SaleVipPrice=? >>>>> where id=? >>>>> 19:34:00,982 INFO [sqlalchemy.engine.base.Engine] (0, 50, 1, 67.5, 67.5, >>>>> Decimal('0.0000'), 0, False, 0.0, False, False, 0, False, 0, 0.0, 0.0, >>>>> 8461) >>>>> but select do. >>>>> >>>>> i'll take your path to dig deeper in mssql/pyodbc layers. >>>>> >>>>> i'd mention paster setup-app development.ini did perform ddl and inserts >>>>> in this >>>>> tg, with the same pyodbc. so i'm still not sure what the difference >>>>> should be. >>>>> >>>>> thanks a lot that far, >>>>> alex >>>>> >>>>> On 11/09/2011 02:27 PM, Julien Tayon wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Le 9 nov. 2011 ŕ 10:35, alex bodnaru <[email protected]> a écrit >>>>>> : >>>>>> >>>>>>> >>>>>>> hello julien, other friends, >>>>>>> >>>>>> Hi alex and friends >>>>>>> the logging was enabled, but info and debug level are the same, since >>>>>>> the query >>>>>>> returns no result: >>>>>>> 11:24:30,872 INFO [sqlalchemy.engine.base.Engine] alter table >>>>>>> tblitemcategories >>>>>>> add SalePrice float(53) DEFAULT (0) NOT NULL; >>>>>> 53 decimal or binary digit ? Why dont you use fixed point numbers for a >>>>>> price ? >>>>>> You are prone to have rounding errors because of using floats (try 38 * >>>>>> 19.6 in >>>>>> float and you'll have a 10e-5 surprise in all languages). In postgres we >>>>>> have >>>>>> the decimal type. You should use it when dealing with prices and taxes. I >>>>>> vaguely remember using it when I was coding in C# on asp .net with mssql >>>>>> 5 or 6. >>>>>>> 11:24:30,872 INFO [sqlalchemy.engine.base.Engine] () >>>>>> Hugh ? How can there is a () >>>>>>> 11:24:30,966 INFO [sqlalchemy.engine.base.Engine] alter table >>>>>>> tblitemcategories >>>>>>> add SaleVipPrice float(53) DEFAULT (0) NOT NULL; >>>>>>> 11:24:30,966 INFO [sqlalchemy.engine.base.Engine] () >>>>>>> >>>>>>> other queries, these related to my permissions, did work and their >>>>>>> results were >>>>>>> logged too, with level DEBUG. >>>>>>> >>>>>>> as i said, the queries reach the dbms, since it reports sql syntax >>>>>>> errors. >>>>>>> >>>>>>> any other ideas about what is preventing their execution/finalization? >>>>>>> >>>>>> Can you higher mssql log verbosity so that mssql can log down to >>>>>> transaction >>>>>> begin / commit / rollback + sql in between so that you know why mssql is >>>>>> unhappy >>>>>> and how SQL is voided (it stinks an implicit rollback). If an exeception >>>>>> is >>>>>> raised during sqlalchemy (because of sql syntax error) I wonder if SA or >>>>>> tg will >>>>>> rollback on its own the transaction. >>>>>> Can you try to catch sqlalchemy SQL syntax errors ? I have no access to >>>>>> my code >>>>>> (being sacked). So I can only give you hints on generic troubleshooting >>>>>> methods. >>>>>> For the sake of caution can you try another driver for mssql (ingres or >>>>>> sybase >>>>>> drivers might do the work if it exists (mssql > 5 +-1 is rebranding of >>>>>> one of >>>>>> those two) , odbc, whatever works). While I dont think it comes from the >>>>>> driver, >>>>>> it cames only as a caution for eliminating a suspect. >>>>>>> best regards, >>>>>>> alex >>>>>>> >>>>>>> On 11/08/2011 04:15 PM, alex bodnaru wrote: >>>>>>>> >>>>>>>> thanks a lot julien for your answer. >>>>>>>> >>>>>>>> i did try the first idea, and will try the second right now. >>>>>>>> >>>>>>>> thank again, >>>>>>>> alex >>>>>>>> >>>>>>>> On 11/08/2011 02:02 PM, julien tayon wrote: >>>>>>>>> If you suspect a rollback in the controller why dont you try to force >>>>>>>>> the transaction commit ? >>>>>>>>> if I remember correctly it could look like : >>>>>>>>> import transaction >>>>>>>>> transaction.commit() >>>>>>>>> >>>>>>>>> And why dont you change sqlalchemy log level to debug and echo = True >>>>>>>>> to troubleshoot your problems ? >>>>>>>>> >>>>>>>>> hf, gl >>>>>>>>> >>>>>>>>> Jul >>>>>>>>> 2011/11/8 alex bodnaru <[email protected]>: >>>>>>>>>> >>>>>>>>>> hello friends, >>>>>>>>>> >>>>>>>>>> i'm trying to perform a few ddl actions through sqlalchemy >>>>>>>>>> dbsession.execute(sql) >>>>>>>>>> >>>>>>>>>> if the sql is wrong, i'm getting an error screen with the relevant >>>>>>>>>> message >>>>>>>>>> from >>>>>>>>>> mssql, hence the execute reaches the rdbms (even with no explicit >>>>>>>>>> flush). >>>>>>>>>> >>>>>>>>>> otherwise, with correct sql i get no visible error, but still the >>>>>>>>>> actions >>>>>>>>>> don't >>>>>>>>>> take effect on the server, hence i suspect some kind of rollback >>>>>>>>>> follows the >>>>>>>>>> execute. >>>>>>>>>> >>>>>>>>>> i mention that i could do similar actions with the same db-user, even >>>>>>>>>> through >>>>>>>>>> sqlalchemy, but not turbogears controller. >>>>>>>>>> but similar(ddl) sql has been correctly run on setup-app. i'm also >>>>>>>>>> trying >>>>>>>>>> explicit flushing session and committing the transaction after >>>>>>>>>> dbsession.execute >>>>>>>>>> like there, but still no result in the db. >>>>>>>>>> >>>>>>>>>> could you help? >>>>>>>>>> >>>>>>>>>> thanks in advance, >>>>>>>>>> alex >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>>> Groups >>>>>>>>>> "TurboGears" group. >>>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [email protected]. >>>>>>>>>> For more options, visit this group at >>>>>>>>>> http://groups.google.com/group/turbogears?hl=en. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups >>>>>>> "TurboGears" group. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected]. >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/turbogears?hl=en. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "TurboGears" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/turbogears?hl=en. >>>>> >>>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "TurboGears" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/turbogears?hl=en. >> > -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
