I'm stuck having to work with MSSQL at work. I've done my best to
deal with this monster and to say at the very least Doctrine plays
nicer, a lot nicer, with MSSQL then Propel did. But I'm having the
following problems:
1 - Mssql Dates
MS-SQL dates return an annoying '.000' at the end of them. Doctrine
doesn't seem to handle it. I edited the following file (just the get)
and it seems to work:
$type = $this->getTable()->getTypeOf($dateFieldName);
if ($type == 'date' || $type == 'timestamp')
{
//cludgy fix to solve issue with timestamp of Mssql returning
000 at the
//end of a date
$date = $this->get( $dateFieldName );
if( substr( $date, -6,1 ) == ':' ) {
$date = substr( $date, 0, strlen( $date) - 6).substr
( $date, -2 );
}
return new DateTime($date);
}
else
{
throw new sfException('Cannot call setDateTimeObject() on a
field that is not of type date or timestamp.');
}
}
Outside of the no fancy regular expressions and no minimum string
length checking (which I will introduce once I collect the gambit of
errors generated) I'm wondering if this was the right way to solve the
problem or if I've missed something??
2 - Column names
I'm stuck using long column names. DBLIB (what a bloody mystery that
thing is) drops columns that are longer the 30. With Doctrine's
unique naming mechanism attaching characters to the column names I'm
loosing columns. I tried the whole alias thing but really that was a
hail-marry to start with.
Outside of further introducing my crap code into the install of
Doctrine has anyone any suggestions how to get around this?
I'm sorry that you have to deal with MSSQL, I really am. :) I have it
at work but I conviced by employer to go with MySQL for projects I'm
doing instead.
Now, for your first problem. What Doctrine version are you using?
As far as I know, you can use you your own record class (or, subclass
of it) so you don't have to hack the Doctrine Core directly. That
should clean this up a bit and doesn't keep you from updating your
Doctrine installation.
You might also raise a JIRA ticket for this, there might be something
that the Core developers can do about it. Can't you somehow cast the
datetime fields returned to a real PHP Date object? I'm just shooting
in the dark here, I'm sorry.
Maybe you might be able to install FreeTDS on a Linux server alongside
your MSSQL server instance (virtualization?), that'd releave some of
your pain. Just a suggestion.
@Core_Doctrine_Team: Maybe we could look into supporting the recently
released PHP MSSQL driver by Microsoft?
--Daniel
On 2009-11-08, at 8/November, 2:34 AM, Trevor.Lanyon wrote:
> I'm stuck having to work with MSSQL at work. I've done my best to
> deal with this monster and to say at the very least Doctrine plays
> nicer, a lot nicer, with MSSQL then Propel did. But I'm having the
> following problems:
> 1 - Mssql Dates
> MS-SQL dates return an annoying '.000' at the end of them. Doctrine
> doesn't seem to handle it. I edited the following file (just the get)
> and it seems to work:
> $type = $this->getTable()->getTypeOf($dateFieldName);
> if ($type == 'date' || $type == 'timestamp')
> {
> //cludgy fix to solve issue with timestamp of Mssql returning
> 000 at the
> //end of a date
> $date = $this->get( $dateFieldName );
> if( substr( $date, -6,1 ) == ':' ) {
> $date = substr( $date, 0, strlen( $date) - 6).substr
> ( $date, -2 );
> }
> return new DateTime($date);
> }
> else
> {
> throw new sfException('Cannot call setDateTimeObject() on a
> field that is not of type date or timestamp.');
> }
> }
> Outside of the no fancy regular expressions and no minimum string
> length checking (which I will introduce once I collect the gambit of
> errors generated) I'm wondering if this was the right way to solve the
> problem or if I've missed something??
> 2 - Column names
> I'm stuck using long column names. DBLIB (what a bloody mystery that
> thing is) drops columns that are longer the 30. With Doctrine's
> unique naming mechanism attaching characters to the column names I'm
> loosing columns. I tried the whole alias thing but really that was a
> hail-marry to start with.
> Outside of further introducing my crap code into the install of
> Doctrine has anyone any suggestions how to get around this?
I'm using 1.2.0-BETA1 (packaged with the svn version of symfony). I'm
accessing the M$SQL server from a linux server using pdo_libdb so I'm
not 100% sure what you mean when you're suggesting installing FreeTDS
on the linux server, can you elaborate?
Our billing application uses our M$SQL cluster and I'm mapping to its
tables so I'm sort of hooped as far using something more LAMPy
friendly.
I've not thought to use the customized date object (or even looked to
find where to do that!). Sounds like I have a little project ahead,
thanks for the suggestion!
Thank you for your insight. Very much appreciated!!
On Nov 7, 10:00 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
> I'm sorry that you have to deal with MSSQL, I really am. :) I have it
> at work but I conviced by employer to go with MySQL for projects I'm
> doing instead.
> Now, for your first problem. What Doctrine version are you using?
> As far as I know, you can use you your own record class (or, subclass
> of it) so you don't have to hack the Doctrine Core directly. That
> should clean this up a bit and doesn't keep you from updating your
> Doctrine installation.
> You might also raise a JIRA ticket for this, there might be something
> that the Core developers can do about it. Can't you somehow cast the
> datetime fields returned to a real PHP Date object? I'm just shooting
> in the dark here, I'm sorry.
> Maybe you might be able to install FreeTDS on a Linux server alongside
> your MSSQL server instance (virtualization?), that'd releave some of
> your pain. Just a suggestion.
> @Core_Doctrine_Team: Maybe we could look into supporting the recently
> released PHP MSSQL driver by Microsoft?
> --Daniel
> On 2009-11-08, at 8/November, 2:34 AM, Trevor.Lanyon wrote:
> > Hi,
> > I'm stuck having to work with MSSQL at work. I've done my best to
> > deal with this monster and to say at the very least Doctrine plays
> > nicer, a lot nicer, with MSSQL then Propel did. But I'm having the
> > following problems:
> > 1 - Mssql Dates
> > MS-SQL dates return an annoying '.000' at the end of them. Doctrine
> > doesn't seem to handle it. I edited the following file (just the get)
> > and it seems to work:
> > $type = $this->getTable()->getTypeOf($dateFieldName);
> > if ($type == 'date' || $type == 'timestamp')
> > {
> > //cludgy fix to solve issue with timestamp of Mssql returning
> > 000 at the
> > //end of a date
> > $date = $this->get( $dateFieldName );
> > if( substr( $date, -6,1 ) == ':' ) {
> > $date = substr( $date, 0, strlen( $date) - 6).substr
> > ( $date, -2 );
> > }
> > return new DateTime($date);
> > }
> > else
> > {
> > throw new sfException('Cannot call setDateTimeObject() on a
> > field that is not of type date or timestamp.');
> > }
> > }
> > Outside of the no fancy regular expressions and no minimum string
> > length checking (which I will introduce once I collect the gambit of
> > errors generated) I'm wondering if this was the right way to solve the
> > problem or if I've missed something??
> > 2 - Column names
> > I'm stuck using long column names. DBLIB (what a bloody mystery that
> > thing is) drops columns that are longer the 30. With Doctrine's
> > unique naming mechanism attaching characters to the column names I'm
> > loosing columns. I tried the whole alias thing but really that was a
> > hail-marry to start with.
> > Outside of further introducing my crap code into the install of
> > Doctrine has anyone any suggestions how to get around this?
Hello Trevor,
regarding FreeTDS. PDO_DBLIB is the oldest method/software to access
MSSQL from Linux. FreeTDS is used in our own implementations to access
MSSQL from a Linux server and we never had any trouble but these
implementations don't use Doctrine, so I'm not sure if you can use
FreeTDS. Might be worth a try, though.
And I'm also pretty sure that you aren't using the Beta1 as symfony
1.3 packages the 1.2 branch version so you already get the latest
bugfixes as 1.2 neares completion. :)
I'm here to help, maybe I'll try to replicate your setup but I'm not
sure I have the time right now, sorry.
--Daniel
Sent from my iPhone
On Nov 8, 2009, at 7:58 PM, "Trevor.Lanyon" <trevor.lan...@lanyonconsulting.com
> I'm using 1.2.0-BETA1 (packaged with the svn version of symfony). I'm
> accessing the M$SQL server from a linux server using pdo_libdb so I'm
> not 100% sure what you mean when you're suggesting installing FreeTDS
> on the linux server, can you elaborate?
> Our billing application uses our M$SQL cluster and I'm mapping to its
> tables so I'm sort of hooped as far using something more LAMPy
> friendly.
> I've not thought to use the customized date object (or even looked to
> find where to do that!). Sounds like I have a little project ahead,
> thanks for the suggestion!
> Thank you for your insight. Very much appreciated!!
> On Nov 7, 10:00 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
>> Hey Trevor,
>> I'm sorry that you have to deal with MSSQL, I really am. :) I have it
>> at work but I conviced by employer to go with MySQL for projects I'm
>> doing instead.
>> Now, for your first problem. What Doctrine version are you using?
>> As far as I know, you can use you your own record class (or, subclass
>> of it) so you don't have to hack the Doctrine Core directly. That
>> should clean this up a bit and doesn't keep you from updating your
>> Doctrine installation.
>> You might also raise a JIRA ticket for this, there might be something
>> that the Core developers can do about it. Can't you somehow cast the
>> datetime fields returned to a real PHP Date object? I'm just shooting
>> in the dark here, I'm sorry.
>> Maybe you might be able to install FreeTDS on a Linux server
>> alongside
>> your MSSQL server instance (virtualization?), that'd releave some of
>> your pain. Just a suggestion.
>> @Core_Doctrine_Team: Maybe we could look into supporting the recently
>> released PHP MSSQL driver by Microsoft?
>> --Daniel
>> On 2009-11-08, at 8/November, 2:34 AM, Trevor.Lanyon wrote:
>>> Hi,
>>> I'm stuck having to work with MSSQL at work. I've done my best to
>>> deal with this monster and to say at the very least Doctrine plays
>>> nicer, a lot nicer, with MSSQL then Propel did. But I'm having the
>>> following problems:
>>> 1 - Mssql Dates
>>> MS-SQL dates return an annoying '.000' at the end of them. Doctrine
>>> doesn't seem to handle it. I edited the following file (just the
>>> get)
>>> and it seems to work:
>>> $type = $this->getTable()->getTypeOf($dateFieldName);
>>> if ($type == 'date' || $type == 'timestamp')
>>> {
>>> //cludgy fix to solve issue with timestamp of Mssql returning
>>> 000 at the
>>> //end of a date
>>> $date = $this->get( $dateFieldName );
>>> if( substr( $date, -6,1 ) == ':' ) {
>>> $date = substr( $date, 0, strlen( $date) - 6).substr
>>> ( $date, -2 );
>>> }
>>> return new DateTime($date);
>>> }
>>> else
>>> {
>>> throw new sfException('Cannot call setDateTimeObject() on a
>>> field that is not of type date or timestamp.');
>>> }
>>> }
>>> Outside of the no fancy regular expressions and no minimum string
>>> length checking (which I will introduce once I collect the gambit of
>>> errors generated) I'm wondering if this was the right way to solve
>>> the
>>> problem or if I've missed something??
>>> 2 - Column names
>>> I'm stuck using long column names. DBLIB (what a bloody mystery
>>> that
>>> thing is) drops columns that are longer the 30. With Doctrine's
>>> unique naming mechanism attaching characters to the column names I'm
>>> loosing columns. I tried the whole alias thing but really that
>>> was a
>>> hail-marry to start with.
>>> Outside of further introducing my crap code into the install of
>>> Doctrine has anyone any suggestions how to get around this?
Wow, response from the phone, that's dedication! Thanks for the info.
Unfortunately I have to agree with you on the FreeTDS. According to
everything I've read the only way to integrate PDO and MsSQL in PHP is
with the pdo_dblib. I'll keep my eyes peeled though.
I'm 100% for sure using 1.2.0-BETA1, unless Symfony is lieing. This
is a copy paste from the debug window:
Doctrine Version: 1.2.0-BETA1
According to http://www.doctrine-project.org/download Doctrine-1.2.0-
BETA1 is the most recent branch of Doctrine anyway. If this is a
version issue I'm more then interested if fixing that. Let me know if
I'm mistaken.
Thank you Daniel for all your help!
On Nov 8, 3:39 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
> Hello Trevor,
> regarding FreeTDS. PDO_DBLIB is the oldest method/software to access
> MSSQL from Linux. FreeTDS is used in our own implementations to access
> MSSQL from a Linux server and we never had any trouble but these
> implementations don't use Doctrine, so I'm not sure if you can use
> FreeTDS. Might be worth a try, though.
> And I'm also pretty sure that you aren't using the Beta1 as symfony
> 1.3 packages the 1.2 branch version so you already get the latest
> bugfixes as 1.2 neares completion. :)
> I'm here to help, maybe I'll try to replicate your setup but I'm not
> sure I have the time right now, sorry.
> --Daniel
> Sent from my iPhone
> On Nov 8, 2009, at 7:58 PM, "Trevor.Lanyon" <trevor.lan...@lanyonconsulting.com
> > wrote:
> > Hi Daniel,
> > I'm using 1.2.0-BETA1 (packaged with the svn version of symfony). I'm
> > accessing the M$SQL server from a linux server using pdo_libdb so I'm
> > not 100% sure what you mean when you're suggesting installing FreeTDS
> > on the linux server, can you elaborate?
> > Our billing application uses our M$SQL cluster and I'm mapping to its
> > tables so I'm sort of hooped as far using something more LAMPy
> > friendly.
> > I've not thought to use the customized date object (or even looked to
> > find where to do that!). Sounds like I have a little project ahead,
> > thanks for the suggestion!
> > Thank you for your insight. Very much appreciated!!
> > On Nov 7, 10:00 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
> >> Hey Trevor,
> >> I'm sorry that you have to deal with MSSQL, I really am. :) I have it
> >> at work but I conviced by employer to go with MySQL for projects I'm
> >> doing instead.
> >> Now, for your first problem. What Doctrine version are you using?
> >> As far as I know, you can use you your own record class (or, subclass
> >> of it) so you don't have to hack the Doctrine Core directly. That
> >> should clean this up a bit and doesn't keep you from updating your
> >> Doctrine installation.
> >> You might also raise a JIRA ticket for this, there might be something
> >> that the Core developers can do about it. Can't you somehow cast the
> >> datetime fields returned to a real PHP Date object? I'm just shooting
> >> in the dark here, I'm sorry.
> >> Maybe you might be able to install FreeTDS on a Linux server
> >> alongside
> >> your MSSQL server instance (virtualization?), that'd releave some of
> >> your pain. Just a suggestion.
> >> @Core_Doctrine_Team: Maybe we could look into supporting the recently
> >> released PHP MSSQL driver by Microsoft?
> >> --Daniel
> >> On 2009-11-08, at 8/November, 2:34 AM, Trevor.Lanyon wrote:
> >>> Hi,
> >>> I'm stuck having to work with MSSQL at work. I've done my best to
> >>> deal with this monster and to say at the very least Doctrine plays
> >>> nicer, a lot nicer, with MSSQL then Propel did. But I'm having the
> >>> following problems:
> >>> 1 - Mssql Dates
> >>> MS-SQL dates return an annoying '.000' at the end of them. Doctrine
> >>> doesn't seem to handle it. I edited the following file (just the
> >>> get)
> >>> and it seems to work:
> >>> $type = $this->getTable()->getTypeOf($dateFieldName);
> >>> if ($type == 'date' || $type == 'timestamp')
> >>> {
> >>> //cludgy fix to solve issue with timestamp of Mssql returning
> >>> 000 at the
> >>> //end of a date
> >>> $date = $this->get( $dateFieldName );
> >>> if( substr( $date, -6,1 ) == ':' ) {
> >>> $date = substr( $date, 0, strlen( $date) - 6).substr
> >>> ( $date, -2 );
> >>> }
> >>> return new DateTime($date);
> >>> }
> >>> else
> >>> {
> >>> throw new sfException('Cannot call setDateTimeObject() on a
> >>> field that is not of type date or timestamp.');
> >>> }
> >>> }
> >>> Outside of the no fancy regular expressions and no minimum string
> >>> length checking (which I will introduce once I collect the gambit of
> >>> errors generated) I'm wondering if this was the right way to solve
> >>> the
> >>> problem or if I've missed something??
> >>> 2 - Column names
> >>> I'm stuck using long column names. DBLIB (what a bloody mystery
> >>> that
> >>> thing is) drops columns that are longer the 30. With Doctrine's
> >>> unique naming mechanism attaching characters to the column names I'm
> >>> loosing columns. I tried the whole alias thing but really that
> >>> was a
> >>> hail-marry to start with.
> >>> Outside of further introducing my crap code into the install of
> >>> Doctrine has anyone any suggestions how to get around this?
> Wow, response from the phone, that's dedication! Thanks for the info.
> Unfortunately I have to agree with you on the FreeTDS. According to
> everything I've read the only way to integrate PDO and MsSQL in PHP is
> with the pdo_dblib. I'll keep my eyes peeled though.
> I'm 100% for sure using 1.2.0-BETA1, unless Symfony is lieing. This
> is a copy paste from the debug window:
> Doctrine Version: 1.2.0-BETA1
> According to http://www.doctrine-project.org/download Doctrine-1.2.0-
> BETA1 is the most recent branch of Doctrine anyway. If this is a
> version issue I'm more then interested if fixing that. Let me know if
> I'm mistaken.
> Thank you Daniel for all your help!
> On Nov 8, 3:39 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
>> Hello Trevor,
>> regarding FreeTDS. PDO_DBLIB is the oldest method/software to access
>> MSSQL from Linux. FreeTDS is used in our own implementations to
>> access
>> MSSQL from a Linux server and we never had any trouble but these
>> implementations don't use Doctrine, so I'm not sure if you can use
>> FreeTDS. Might be worth a try, though.
>> And I'm also pretty sure that you aren't using the Beta1 as symfony
>> 1.3 packages the 1.2 branch version so you already get the latest
>> bugfixes as 1.2 neares completion. :)
>> I'm here to help, maybe I'll try to replicate your setup but I'm not
>> sure I have the time right now, sorry.
>> --Daniel
>> Sent from my iPhone
>> On Nov 8, 2009, at 7:58 PM, "Trevor.Lanyon"
>> <trevor.lan...@lanyonconsulting.com
>> > wrote:
>>> Hi Daniel,
>>> I'm using 1.2.0-BETA1 (packaged with the svn version of symfony). >>> I'm
>>> accessing the M$SQL server from a linux server using pdo_libdb so
>>> I'm
>>> not 100% sure what you mean when you're suggesting installing
>>> FreeTDS
>>> on the linux server, can you elaborate?
>>> Our billing application uses our M$SQL cluster and I'm mapping to
>>> its
>>> tables so I'm sort of hooped as far using something more LAMPy
>>> friendly.
>>> I've not thought to use the customized date object (or even looked
>>> to
>>> find where to do that!). Sounds like I have a little project ahead,
>>> thanks for the suggestion!
>>> Thank you for your insight. Very much appreciated!!
>>> On Nov 7, 10:00 pm, Daniel Lohse <annismcken...@googlemail.com>
>>> wrote:
>>>> Hey Trevor,
>>>> I'm sorry that you have to deal with MSSQL, I really am. :) I
>>>> have it
>>>> at work but I conviced by employer to go with MySQL for projects
>>>> I'm
>>>> doing instead.
>>>> Now, for your first problem. What Doctrine version are you using?
>>>> As far as I know, you can use you your own record class (or,
>>>> subclass
>>>> of it) so you don't have to hack the Doctrine Core directly. That
>>>> should clean this up a bit and doesn't keep you from updating your
>>>> Doctrine installation.
>>>> You might also raise a JIRA ticket for this, there might be
>>>> something
>>>> that the Core developers can do about it. Can't you somehow cast
>>>> the
>>>> datetime fields returned to a real PHP Date object? I'm just
>>>> shooting
>>>> in the dark here, I'm sorry.
>>>> Maybe you might be able to install FreeTDS on a Linux server
>>>> alongside
>>>> your MSSQL server instance (virtualization?), that'd releave some
>>>> of
>>>> your pain. Just a suggestion.
>>>> @Core_Doctrine_Team: Maybe we could look into supporting the
>>>> recently
>>>> released PHP MSSQL driver by Microsoft?
>>>> --Daniel
>>>> On 2009-11-08, at 8/November, 2:34 AM, Trevor.Lanyon wrote:
>>>>> Hi,
>>>>> I'm stuck having to work with MSSQL at work. I've done my best to
>>>>> deal with this monster and to say at the very least Doctrine plays
>>>>> nicer, a lot nicer, with MSSQL then Propel did. But I'm having
>>>>> the
>>>>> following problems:
>>>>> 1 - Mssql Dates
>>>>> MS-SQL dates return an annoying '.000' at the end of them. >>>>> Doctrine
>>>>> doesn't seem to handle it. I edited the following file (just the
>>>>> get)
>>>>> and it seems to work:
>>>>> $type = $this->getTable()->getTypeOf($dateFieldName);
>>>>> if ($type == 'date' || $type == 'timestamp')
>>>>> {
>>>>> //cludgy fix to solve issue with timestamp of Mssql
>>>>> returning
>>>>> 000 at the
>>>>> //end of a date
>>>>> $date = $this->get( $dateFieldName );
>>>>> if( substr( $date, -6,1 ) == ':' ) {
>>>>> $date = substr( $date, 0, strlen( $date) - 6).substr
>>>>> ( $date, -2 );
>>>>> }
>>>>> return new DateTime($date);
>>>>> }
>>>>> else
>>>>> {
>>>>> throw new sfException('Cannot call setDateTimeObject() on a
>>>>> field that is not of type date or timestamp.');
>>>>> }
>>>>> }
>>>>> Outside of the no fancy regular expressions and no minimum string
>>>>> length checking (which I will introduce once I collect the
>>>>> gambit of
>>>>> errors generated) I'm wondering if this was the right way to solve
>>>>> the
>>>>> problem or if I've missed something??
>>>>> 2 - Column names
>>>>> I'm stuck using long column names. DBLIB (what a bloody mystery
>>>>> that
>>>>> thing is) drops columns that are longer the 30. With Doctrine's
>>>>> unique naming mechanism attaching characters to the column names
>>>>> I'm
>>>>> loosing columns. I tried the whole alias thing but really that
>>>>> was a
>>>>> hail-marry to start with.
>>>>> Outside of further introducing my crap code into the install of
>>>>> Doctrine has anyone any suggestions how to get around this?
I looked at the entries file in the lib/vendor/symfony/lib/plugins/
sfDoctrinePlugin/lib/vendor/doctrine directory and sure enough it's
pointing to http://doctrine.mirror.svn.symfony-project.com/branches/1.2/lib like you said. Sorry I provided the incorrect version. I was going
off the web tool bar. Next time I'll try not to take less for
granted.
I submitted the mssql date issue via a JIRA ticket. Hopefully it gets
looked at. This problem is annoying further as it also effects
sfDateTimeWidget. The widget has no values as it can't part the
format properly. Uhg.
Although I wasn't able to resolve my issue I appreciate your
suggestions. Thank you again!
On Nov 9, 9:49 am, Daniel Lohse <annismcken...@googlemail.com> wrote:
> As for the version constant: it has not been updated but it should be
> '1.2.0-DEV' and not '1.2.0-BETA1'. :)
> And you're right regarding FreeTDS. It would be the best method to
> access MSSQL but it doesn't work with PDO. -.-
> --Daniel
> Sent from my iPhone
> On 2009-11-09, at 9/November, 2:17 PM, Trevor.Lanyon wrote:
> > Hi Daniel,
> > Wow, response from the phone, that's dedication! Thanks for the info.
> > Unfortunately I have to agree with you on the FreeTDS. According to
> > everything I've read the only way to integrate PDO and MsSQL in PHP is
> > with the pdo_dblib. I'll keep my eyes peeled though.
> > I'm 100% for sure using 1.2.0-BETA1, unless Symfony is lieing. This
> > is a copy paste from the debug window:
> > Doctrine Version: 1.2.0-BETA1
> > According tohttp://www.doctrine-project.org/downloadDoctrine-1.2.0- > > BETA1 is the most recent branch of Doctrine anyway. If this is a
> > version issue I'm more then interested if fixing that. Let me know if
> > I'm mistaken.
> > Thank you Daniel for all your help!
> > On Nov 8, 3:39 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
> >> Hello Trevor,
> >> regarding FreeTDS. PDO_DBLIB is the oldest method/software to access
> >> MSSQL from Linux. FreeTDS is used in our own implementations to
> >> access
> >> MSSQL from a Linux server and we never had any trouble but these
> >> implementations don't use Doctrine, so I'm not sure if you can use
> >> FreeTDS. Might be worth a try, though.
> >> And I'm also pretty sure that you aren't using the Beta1 as symfony
> >> 1.3 packages the 1.2 branch version so you already get the latest
> >> bugfixes as 1.2 neares completion. :)
> >> I'm here to help, maybe I'll try to replicate your setup but I'm not
> >> sure I have the time right now, sorry.
> >> --Daniel
> >> Sent from my iPhone
> >> On Nov 8, 2009, at 7:58 PM, "Trevor.Lanyon"
> >> <trevor.lan...@lanyonconsulting.com
> >> > wrote:
> >>> Hi Daniel,
> >>> I'm using 1.2.0-BETA1 (packaged with the svn version of symfony).
> >>> I'm
> >>> accessing the M$SQL server from a linux server using pdo_libdb so
> >>> I'm
> >>> not 100% sure what you mean when you're suggesting installing
> >>> FreeTDS
> >>> on the linux server, can you elaborate?
> >>> Our billing application uses our M$SQL cluster and I'm mapping to
> >>> its
> >>> tables so I'm sort of hooped as far using something more LAMPy
> >>> friendly.
> >>> I've not thought to use the customized date object (or even looked
> >>> to
> >>> find where to do that!). Sounds like I have a little project ahead,
> >>> thanks for the suggestion!
> >>> Thank you for your insight. Very much appreciated!!
> >>> On Nov 7, 10:00 pm, Daniel Lohse <annismcken...@googlemail.com>
> >>> wrote:
> >>>> Hey Trevor,
> >>>> I'm sorry that you have to deal with MSSQL, I really am. :) I
> >>>> have it
> >>>> at work but I conviced by employer to go with MySQL for projects
> >>>> I'm
> >>>> doing instead.
> >>>> Now, for your first problem. What Doctrine version are you using?
> >>>> As far as I know, you can use you your own record class (or,
> >>>> subclass
> >>>> of it) so you don't have to hack the Doctrine Core directly. That
> >>>> should clean this up a bit and doesn't keep you from updating your
> >>>> Doctrine installation.
> >>>> You might also raise a JIRA ticket for this, there might be
> >>>> something
> >>>> that the Core developers can do about it. Can't you somehow cast
> >>>> the
> >>>> datetime fields returned to a real PHP Date object? I'm just
> >>>> shooting
> >>>> in the dark here, I'm sorry.
> >>>> Maybe you might be able to install FreeTDS on a Linux server
> >>>> alongside
> >>>> your MSSQL server instance (virtualization?), that'd releave some
> >>>> of
> >>>> your pain. Just a suggestion.
> >>>> @Core_Doctrine_Team: Maybe we could look into supporting the
> >>>> recently
> >>>> released PHP MSSQL driver by Microsoft?
> >>>> --Daniel
> >>>> On 2009-11-08, at 8/November, 2:34 AM, Trevor.Lanyon wrote:
> >>>>> Hi,
> >>>>> I'm stuck having to work with MSSQL at work. I've done my best to
> >>>>> deal with this monster and to say at the very least Doctrine plays
> >>>>> nicer, a lot nicer, with MSSQL then Propel did. But I'm having
> >>>>> the
> >>>>> following problems:
> >>>>> 1 - Mssql Dates
> >>>>> MS-SQL dates return an annoying '.000' at the end of them.
> >>>>> Doctrine
> >>>>> doesn't seem to handle it. I edited the following file (just the
> >>>>> get)
> >>>>> and it seems to work:
> >>>>> $type = $this->getTable()->getTypeOf($dateFieldName);
> >>>>> if ($type == 'date' || $type == 'timestamp')
> >>>>> {
> >>>>> //cludgy fix to solve issue with timestamp of Mssql
> >>>>> returning
> >>>>> 000 at the
> >>>>> //end of a date
> >>>>> $date = $this->get( $dateFieldName );
> >>>>> if( substr( $date, -6,1 ) == ':' ) {
> >>>>> $date = substr( $date, 0, strlen( $date) - 6).substr
> >>>>> ( $date, -2 );
> >>>>> }
> >>>>> return new DateTime($date);
> >>>>> }
> >>>>> else
> >>>>> {
> >>>>> throw new sfException('Cannot call setDateTimeObject() on a
> >>>>> field that is not of type date or timestamp.');
> >>>>> }
> >>>>> }
> >>>>> Outside of the no fancy regular expressions and no minimum string
> >>>>> length checking (which I will introduce once I collect the
> >>>>> gambit of
> >>>>> errors generated) I'm wondering if this was the right way to solve
> >>>>> the
> >>>>> problem or if I've missed something??
> >>>>> 2 - Column names
> >>>>> I'm stuck using long column names. DBLIB (what a bloody mystery
> >>>>> that
> >>>>> thing is) drops columns that are longer the 30. With Doctrine's
> >>>>> unique naming mechanism attaching characters to the column names
> >>>>> I'm
> >>>>> loosing columns. I tried the whole alias thing but really that
> >>>>> was a
> >>>>> hail-marry to start with.
> >>>>> Outside of further introducing my crap code into the install of
> >>>>> Doctrine has anyone any suggestions how to get around this?
|
