Thanks. My provider finally informed me to set different extension-dir in web env and cli env, they said this is due to security issue. And then after callign different php.ini, it works.
On Tue, Apr 7, 2009 at 7:18 AM, Ant Cunningham <[email protected] > wrote: > > I may be mistaken as ive never had that issue.. But i would think that > means they dont have the extension enabled in the base ini. > > I do know that when calling php from the cli you can specify the ini to > use. ive never used the switch so i dont know if it uses only the ini > specified or if it "merges" them with the custom one overriding the > base. in any case you could try using > > php [options] symfony taskset:command [args] > > using one of these option switches: > > -c <path>|<file> Look for php.ini file in this directory > -d foo[=bar] Define INI entry foo with value 'bar' > > xhe wrote: > > I found, my hosting provider compiled php with PDO as shared library, > > maybe that is why backend CLI can not find the PDO class. > > > > In web environment, if I include these: > > extension=pdo.so in my php.ini, PDO class can be easily imported and > > used in the website. > > But in CLI, this line can not import PDO class and script can not find > > it at all. > > > > Please, anyone if using shared hosting service with PDO compiled as > > shared library, can you use symfony 1.2 task in CLI environment? If > > so, how do you use it? > > > > Thanks > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
