Hi Scott, > ...to develop on Windows and deploy on Linux. It sounds > like pyodbc is the best option
pyodbc works well in Windows, but I've heard on Linux, not so much. pymssql is your best bet for Linux. Note that pymssql does not work with unicode, limits SQL identifiers to 30 characters, and will only support up to 255 chars in VARCHAR columns. We could use some help getting pyodbc on Linux in good shape, I'm far too busy these days to assist much. > I saw an archived email that said there was better support for > MSSQL in 0.3 than in 0.4. Is that still the case? yeah, sadly MSSQL is pretty lighly tested on 0.4 right now. AFAIK, it's not part of the regular test cycle. > I'll be piggy backing on an existing ERP system and I'm trying to > decide what would be the best way to store new tables Well if you want to join against those other tables, and I'm guessing you do, you'd be far better off using the same DB engine as the current system. Doesn't have to be the same database, MSSQL works fine in cross-database joins. SQLite is a great little database engine, but beware trying to make it scale up for highly concurrent situations. It's fast as hell as long as there are only readers, or only writers, but mix the two and it will fall over pretty fast. We use it here very successfully as a "static" database repository, for geocode caches, user settings, archive data, that kind of stuff. If you're going to have lots of simultaneous users and hitting the tables hard, I would go with something designed for concurrent access. HTH, Rick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
