Hi Massimo:

Thank you for considering those MSSQL issues.

Another DAL – related issue is the errors of some apps on some SQL
engines caused by the use of reserved words as column names
T3 appears to have this issue on SQL Server:

In t2.py line 355, it uses the SQL Server reserved word 'file' as a
column name and so gets a SQL Server Exception
when trying to create the t2_attachment table:
            t=db.define_table('t2_attachment',T2.base_table
(db,'t2_attachment'))
            t.exposes=['name','description','file']

I think 'name' is also a reserved word.

So, on SQL Server I believe it would have to be '[name]' and
'[file]'   i.e. in Square Brackets
Or they have to be renamed for example t2_name and t2_file.

However I tried a simple rename via search and replace but then other
exceptions occurred.
It is not obvious where to make all the renaming changes throughout
the  T3 code.

At the moment I am not able to run T3 totally using SQL Server due to
this issue.
But I worked around it: I created 2 SQL Connections - 'db' as usual on
SQL Lite. and my own dbmssql for
use with new tables I created to add to the existing T3 tables.  My
target is GAE but I'm just mixing in some SQL Server for temporary
ease of development.

Please consider implementing some framework features to avoid this
problem.

Thanks.
- Dave Lypka.


On May 31, 11:45 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> this can definitively be done.
>
> On May 31, 3:41 am, dlypka <dly...@gmail.com> wrote:
>
>
>
> > Hi Massimo
>
> > FYI: Some issues to note as you are rewriting the DAL:
>
> > 1. For mssql connections, I want to write:
> >     db = SQLDB('mssql://dlypka:p...@word1@localhost/TMoMilestones')
> > The '@' delimiter is a problem for me because '@' is a legal, often
> > used character in SQL Server passwords
> > So please at least change the regular expression in sql.py line 768 to
> > allow enclosing the password in perhaps square brackets
> > So for example, it would allow
>
> >    db = SQLDB('mssql://dlypka: [p...@word1]@localhost/TMoMilestones')
>
> > The re at line 768 is
> >                     re.compile('^(?P<user>[^:@]+)(\:(?P<passwd>[...@]*))?
> > @(?P<host>[^\:/]+)(\:(?P<port>[0-9]+))?/(?P<db>.+)$'
> >                                ).match(self._uri[skip:])
>
> > 2. Please change sql.py to use pymssql rather than pyodbc
> >     pymssql Version 1.0.2 was released on 2009-04-28. It has major bug
> > fixes and works well now.
> >     I got it from herehttp://pymssql.sourceforge.net/
>
> > I suggest changing sql.py line 791:
> > #            self._pool_connection(lambda : pyodbc.connect(cnxn))
> >             self._pool_connection(lambda : pymssql.connect(cnxn)
>
> > 3. Please provide a way to specify options such as trusted=True
> > For example, I need to call it this way:
> >             self._pool_connection(lambda : pymssql.connect
> > (host='',trusted=True,database=db))
>
> > Thank you.
> > - Dave Lypka.
>
> > On May 30, 12:43 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > Yes, it will be backward compatible unless you used internal and
> > > undocumented features of the DAL (like importing SQLSet or subclassing
> > > SQLRows). it will also expose a new alternative cleaner syntax (for
> > > example you will be asked to use Field instead of SQLField but
> > > SQLField works too as alias of Field).
>
> > > I will explain more when done.
>
> > > Massimo
>
> > > On May 29, 8:29 pm, cesmiga <cesm...@gmail.com> wrote:
>
> > > > Massimo,
>
> > > > Will the new DAL be backwards compatible with the existing DAL?  The
> > > > reason I ask is because I have been using "WWW SQL Designer" and hope
> > > > to continue using it with the new DAL.
>
> > > > Thank you,
> > > > Christopher
>
> > > > mdipierro wrote:
> > > > > I am finishing a rewrite of the new DAL. It may be done in one week or
> > > > > two but I could use some help.
> > > > > I can explain exactly what to do. I need people to write and run tests
> > > > > for the supported backends.
>
> > > > > It will be beackward compatible and have some new features including
> > > > > dealing with tables that do not have the 'id' field, realnames
> > > > > different than virtualnames for tables and columns, a certain degree
> > > > > of fail safety when multiple databases present, and be very modular
> > > > > and extensible (to add new engines and new fields and add methods to
> > > > > handle the fields values). It is also be smaller and I think faster
> > > > > than the old one.
>
> > > > > Yes, this is possible and already have it working for sqlite.
>
> > > > > Let me know if you can help. I need a serious commitment and proven
> > > > > expertise on this list.
>
> > > > > Massimo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to