I get the "Zend Guard Run-time support missing!" page even though I have Zend Guard Loader installed and properly configured.
I have a Windows 2008 server with IIS 7 and PHP 5.4.42 which is a non-threadsafety version.
I need PHP 5.3 or 5.4 for the TemplateMonster.com template that I am trying to use.
I have added these lines to my php.ini file:
zend_loader.enable=1
zend_extension="C:\Program Files\ZEND\v5.4\ZendLoader.dll"
When I use the command php -v I get this:
PHP 5.4.24 (cli)(built: Jan 8 2014 20:26:10)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies
Tech support at TemplateMonster suggests that the permissions need to be set properly and give me a list of linux permissions to set for specific files and folders. When I ask for Windows specific permission settings they can not help me, but confirm the template will work on a windows server. I have successfully setup the template on a test server but still cannot get the templete working on the production server. I did not set any permissions on the test server.
I have given read/write and execute permissions to the IUSR_MyServer user for the entire file set.
I have read every article I can find on this subject and am at an end to my ideas of what is wrong here. I sure hope someone can help. Thank you in advance.
Solved! I had downloaded the wrong version of PHP. I downloaded the Non-threaded safety version and bingo! All is now working.
Related
I have trouble when I try to upload an Excel file, I've searched in a lot of places how to solve this, but the solution the give (only install Microsoft Access Database Engine 2010 Redistributable) doesn´t work for me. I have VS2017 and I've installed Microsoft Access Database Engine 2010 Redistributable, I´m kinda new doing this so I donn´t know what I´m missing.
Thanks
a pleasure to greet you, an hour ago I had the same problem, the only thing I did was download both versions (both the 32-bit and the 64-bit version) and the first thing I did was install the 64-bit version of normal way, downloading from the official page, but I installed the 32-bit version from Command Prompt with the following code:
CD: [path]/AccessDataEngine.exe /passive
in this way I managed to solve that error
I need to migrate an enterprise production database from a Windows source machine running Postgres 9.5 to an Ubuntu destination machine running Postgres 11.6 with < 15 mins downtime. I plan to do this with pglogical, which requires the extension being loaded on both source and destination. I am having trouble with the source side because it is Windows.
I have very little Postgres-Windows experience and can neither find any helpful literature on the specific situation nor can I figure out for myself how to presumably install from source.
I've dug and dug and so far the only answer I've been able to find is "ugh... Windows". It seems like the only way to build from source is using Visual Studio, which I don't have or know how to use.
Sources:
https://www.2ndquadrant.com/en/blog/compiling-postgresql-extensions-visual-studio-windows/
https://postgrespro.ru/list/thread-id/1835275
Alex, the 2ndQuadrant article you link to in your own comment solves this. A few of the project or build options noted there have moved a little bit in the newer VisualStudio Community editions, so I can see where you got hung-up.
Just for kicks I compiled 32-bit DLL on my oldest Windows instance. I included the /Release path so you can grab my DLL & see if it works for you. It's (a) 32-bit because I'm assuming worst-case for an old v9.5 install, and (b) targets Postgres 9.6 because that's what I had installed. Unless there were major API changes though, it should connect to v9.5 without any issues:
https://github.com/mbijon/winpglogical/tree/master
If you find you need a version that entirely matches Postgres 9.5, grab my solution files & VS Community 20xx. Load the project & update the Additional Include Directories in Project Config to target your v9.5 paths. That should be all that's needed to link v9.5 Postgres libs.
I try to run Zend Server 9.1 with Developer License on centOS 7.3 (selinux disabled), installed by Zend-Installer bash-script.
However, the admin interface is
a) very slow
b) gives me "General error 5: database is locked" when trying to save stuff.
I figured out, that lighttpd is locking the DB all the time (usr/local/zend/var/db/zsd.db). Reinitiating the zsd.db file etc. doesnt help.
As soon as I stop the lighttpd process, the database becomes available again.
Any hints, why lighttpd would lock the DB all the time ?
Thx in advance,
Frank
It is hard to give you the reason with out checking the logs file. You can generate Zend Server Support Tool and check the(zend_server_ui.log,zsd.log) logs for the exact reason behind database log.
http://files.zend.com/help/Zend-Server/content/support_tool.htm
However, you can also check the logs from Zend Server UI| Monitoring | Logs.
Win 2007 Server 32bit
Apache2.2
PHP version 5.3.14 which was without php_oci8 files
oracle Enterprise Edition installed
I need to be able to connect to remote oracle database, so I find out, that OCI8 extension should be used. To make OCI8 work, I also should need at least Oracle Instant Client on server, because of certain DLL OCI8 need.
What I did?
downloaded Oracle Instant Client from their sites ( oracle download site ), version 11.2.0.4.0
unpacked into folder, I choosed Program Files/oci_11_2
added to windows variable path the address
restarted Win
downloaded php_oci8 libraries from PECL ( PECL oci8 dl site )
put them into the ext directory set in php.ini
added extension=php_oci8.dll into php.ini
restarted apache
After all this I checked php_info to see, if everything is ok, however no signs of oci8.
I tried older Oracle instant client, swtiching between php_oci8.dll, php_oci8_11g.dll or php_oci8_12c.dll, yet nothing helped.
Currently, I have no idea what to do, unless trying reinstalling php(which I don't want to because of many problematics connected with that), different Oracle instant clients or differenct php_oci8 libraries. I google for some hours, tried looking on Stack, but no solution, just some tips, that didn't help. Have someone encountered and solved something similar?
you've got to set ORACLE_HOME and LD_LIBRARY_PATH Apache environment variables too.
You have to:
set ORACLE_HOME to point to the Instant Client root folder,
enable PHP_OCI8_SOMETHING.DLL in your PHP.INI config (... which you did),
restart Windows, ideally,
start Apache.
... and it should work.
Ideally you would do this under the Windows account which owns+runs the Apache+PHP server (which should be other than that which you use regularly; this way you can have several Oracle homes concurrently in use on your Windows), so one more ...
check the filesystem privileges - whether the Instant Client is accessible to the Apache process.
I previously installed a website on the server by running an msi package and everything worked fine. Now, when I try to run the same msi file (to Repair/Uninstall), I get a message:
When I click Cancel, I get the following message:
Anybody has an idea what happened and how it can be fixed?
I would recommend that you run the MSI with logging enabled. This can be done by using the /l*v C:\mylog.txt switch or by modifying the registry. The log will provide you with more precise information as to what is going wrong during the msi process.
The articles below describe how to enable logging and the logging process in more detail
http://support.microsoft.com/kb/223300
http://technet.microsoft.com/en-us/library/cc759262(v=WS.10).aspx
http://msdn.microsoft.com/en-us/library/aa372847(v=vs.85).aspx
Once you have the log you can use a set of MSI tools like the Orca installer database editor tool on the Windows SDK to correct any issues.
This is the link for Windows 7 SDK which contains the msi tools.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Sorry for answering my own question, but I found the problem and I want to share the solution:
After I installed the old version on the server, I changed the name of the msi file. Consequently, I could not run the old version to repair/update. I could not even install a newer version over the old version, as the installer needed the old msi to uninstall the old version.
When I changed back the filename of the old version, it allowed me to install the new version.
CONCLUSION: Don't change the name of the msi file after installation.