I have Oracle 12c r1 installed on my Fedora 27 64bit pc and now I want to install Oracle Forms
But the problem is that Oracle Fusion infrastructure needs to be installed on different Oracle_Home and after installing it and when I start Installing Oracle Forms and Oracle reports the installation never finish And get stuck at 98% and when I check the log it looks like that the install program looking for files in the other Oracle_home (the old home)
Where my database is!
Someone told me the the full installation of Oracle Forms includes Oracle Database of the same version so I do not need my old 12c data base installation, is this true?
I've never installed Fusion nor Forms before and I do not know how install them correctly on the same machine as my database, so can anyone help me please ?
Thanks
I'm not the expert in Oracle Forms installation, but I may have some useful information for you.
First of all - what version of Fusion Middleware are you trying to install? It's important because Oracle Forms&Reports is very demanding in matter of OS and much more tricky than Oracle Database. You should install it only on supported ones. It's connected with packages and libraries. If you have too new, you may expect strange problems.
For 12.2.1.3.0 the supported OS's are:
Oracle Linux 6,
Oracle Linux 7,
Red Hat Enterprise Linux 6,
Red Hat Enterprise Linux 7,
SLES 11,
SLES 12.
Fedora 19 is clone of RHEL 7, maybe Fedora 27 is too new? I couldn't find any info about it... DBA in our company told me once: "Never try to install Oracle software on configuration which is not directly supported by Oracle - it's asking for troubles. You should always do as Installation Guide states."
Maybe you should tried installing Fusion Middleware on separate Virtual Machine using one of mentioned OS's? In my opinion it's much more safe to have Oracle Fusion Middleware installed on VM than on bare-metal PC. It's easy to backup, easy to migrate to other server etc. The supported one is Oracle VM, but you should not have problems with VMware (I know that FMW 11 works on VMware, never tried 12).
Someone told me the the full installation of Oracle Forms includes
Oracle Database of the same version so I do not need my old 12c data
base installation, is this true?
According to this Guide - no, it does not. But I know other products that comes with Oracle DB in package (like Oracle Business Intelligence, which consist of Oracle DB, Weblogic and OBI as middleware) - so maybe it's not all true.
New information (2018-04-26):
Ok, I've asked a more experienced DBA and he told me that it is common to use another linux user account to install other oracle software on the same PC. Then you can easily set completely different environments, so you can avoid glitches. For example you can set for them different ORACLE_HOME.
It is not necessary to have multiple user accounts if you isolate the environments. For multiple Oracle product installs on the same server I use shell scripts to set the ENV for each one.
Ensure that your current ENV does not have any Oracle Database references - check .bashrc .bash_profile and run: printenv to verify.
Example: database env script
#!/bin/sh
#
# Defining environment variables for Oracle Database.
#
ORACLE_BASE=/u01/app/oracle
export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/12.1.0/dbhome_1
export ORACLE_HOME
TNS_ADMIN=$ORACLE_HOME/network/admin
export TNS_ADMIN
JAVA_HOME=$ORACLE_HOME/jdk
export JAVA_HOME
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib
export LD_LIBRARY_PATH
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$JAVA_HOME/bin:$PATH
export PATH
Source the env script and start listener and database from shell - database needs to be running for the middleware install
Install Java 8 JDK from oracle.com/technology - I download the tar gzip file and extract to /u01/app/oracle/product/jdk8 {better to use a generic name for the folder jdk8 vs the release number as it is easier to upgrade the jdk}
Set ENV for install:
ORACLE_BASE=/u01/app/oracle
export ORACLE_BASE
JAVA_HOME=/u01/app/oracle/product/jdk8
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
Source ENV for install in shell
Start middleware infrastructure installation from same shell (this part does not require the config to be run)
Create Repository: cd to middleware infrastructure home/oracle_common/bin
Run ./rcu -> Common Infrastructure Services/Oracle Platform Security Services and prefix
Install FMW (same shell as infrastructure)
Run config.sh
Post Install: may require symlink to be created if an error - cd /usr/lib64 - ln -s libXm.so.4 libXm.so.3
Create shell script to set FMW env
#!/bin/sh
#
# 12c Fusion Middleware Environment
#
ORACLE_HOME=/u01/app/oracle/product/m12.2
export ORACLE_HOME
JAVA_HOME=/u01/app/oracle/product/jdk8
export JAVA_HOME
PATH=$ORACLE_HOME/OPatch:$ORACLE_HOME/wlserver/common/bin:$ORACLE_HOME/oracle_common/common/bin
export PATH
Source the FMW ENV script then cd $ORACLE_HOME and start the processes
I have found that using the shell and environment isolation works well.
The FMW/Infrastructure requires Java 8 - I have run into issues in the past trying to use OpenJDK for FMW - using the Oracle Java 8 JDK seems to work better.
These were my notes for an install on Redhat 7 - should work on Fedora but may require some troubleshooting - sometimes libraries are newer than the version FMW requires or are missing. Not sure if you installed the Repository in your attempts - if not that might have been why the install hangs - it is trying to connect to the database and update the repository tables.
Refer to the Installation guides for more information
hope that helps you.
Related
In my current workplace we are using MariaDB version 10.5.9 for our DB's and we are trying to reinstall this version for testing purposes on a separate container. However, seems anything from 10.5.9 below is failing with the follow error;
root#mdb-10-5:~# curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version=mariadb-10.5.9
# [info] Checking for script prerequisites.
# [warning] Found existing file at /etc/apt/sources.list.d/mariadb.list. Moving to /etc/apt/sources.list.d/mariadb.list.old_5
# [error] MariaDB Server version 10.5.9 is not working.
# Please verify that the version is correct.
#
# The latest MariaDB Server versions are:
# 10.10.1 10.3.36 10.4.26 10.5.17 10.6.10 10.7.6 10.8.5 10.9.3
#
# More information on MariaDB releases is available at:
# https://mariadb.com/kb/en/release-notes/
When I try the same command with version 10.5.10, it works and downloads successfully.
I am using the following procedure, one of which is the MariaDB KB:
https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/
https://www.dbi-services.com/blog/how-to-install-a-specific-version-of-mariadb/
Both guides use the same repo, and it is also the only thing that I have found specific when I search for information to install this particular version or MariaDB.
Can anyone offer any suggestions or have experienced similar problems?
We (MariaDB corporation) recently moved over our repositories to a content delivery network instead of using our own servers only. Unfortunately the new service does not have a full archive of older releases yet, the oldest 10.5 we have on there for example is 10.5.10.
I have filed an internal bug report / feature request about that already, but it is still pending.
Meanwhile you can "fix" this by first running the repo setup script with a supported version like 10.5.10, and then editing the repository file it created, replacing the version number with 10.5.9, and the host name dlm.mariadb.com with download.mariadb.com.
On Debian and Ubuntu the repository file would be /etc/apt/sources.list.d/mariadb.list, and you'd have to run apt-get update afterwards to pick up the repo change before installing packages.
On RHEL, CentOS, Rocky etc. the file is /etc/yum.repos.d/mariadb.repo and no further action is needed before installing actual packages.
I'm building an ASP.NET Core 2.0 Web API application that is hosted in an Ubuntu environment. So far, I've had great success getting things building and running (for the .NET Core app) in Ubuntu.
For the database, I have a SqlProj included in my solution. The project includes typical things such as tables, SPs, and pre/post deployment scripts. I'm using the following command (on my Windows-based dev machine) to build and deploy this project:
msbuild .\MyProject.DB.sqlproj /t:Build /t:Publish /P:SqlPublishProfilePath="./PublishProfiles/MyProject.DB.publish.xml"
When I take this approach, everything builds and deploys properly; however, since I will be taking advantage of the .NET Core CLI commands + CI/CD that targets an Ubuntu environment, I'd like to do something more like:
dotnet msbuild .\MyProject.DB.sqlproj /t:Build /t:Publish /P:SqlPublishProfilePath="./PublishProfiles/MyProject.DB.publish.xml"
In Windows, I immediately get the error:
error MSB4019: The imported project "C:\Program Files\dotnet\sdk\2.1.4\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Basically, what I'm asking is how to successfully build and deploy a SqlProj project in an Ubuntu environment. I've tried Googling, but I have had zero luck thus far. All of the similar issues that I've found were for individuals who were editing their .proj file to target their VS folder's SSDT. All of these individuals were fixing the issue in Windows. This approach will not work in Ubuntu, since the targets file uses Windows registry keys.
EDIT: I'm aware that SSDT is needed in order to perform such a deployment using MSBuild. I've found no evidence that installing/using SSDT is even possible in Ubuntu. If it is not, perhaps there is an alternative solution?
FYI, I'm aware that using a code-first approach with EF Core is possible. I'm attempting to take the raw SP approach (along with leveraging indexes) and keep track of all of my code using SqlProj instead. This will all be stored and CI/CDed from a Git repo.
You can use this NuGet package to deploy without installing SSDT https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild
I don't know if it will run on Ubuntu or integrate at all with the dotnet cli
My 2020 Solution
I would like to revisit this in 2020 with an updated answer to my original question.
I have taken a different approach to building an deploying SQL Server projects. My current approach is to build a pipeline that uses a vs2017-win2016 agent and use this to build a .dacpac. From there, you build a deployment pipeline to deploy the dacpac (from your artifact drop) out to the SQL Server instance.
This approach better accommodates DevOps methodologies and removes the manual process associated with my previous solution.
You can read more about this here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/apps/aspnet/build-aspnet-dacpac?view=azure-devops
I can't speak to whether or not this will work on Ubuntu, but we recently got through this on a Windows build machine that does not have SSDT installed, using the NuGet package mentioned above. The breakthrough came from piecing together the details in the article below, specifically that using the SDK with MSBuild needed to have environment variables set in order to work.
https://blogs.msdn.microsoft.com/ssdt/2016/08/22/part-5-use-your-own-build-and-deployment-agent/
With that added info, we installed the NuGet package in the root of the solution folder and then wrote a build script in PowerShell. The script sets the environment variables first and then calls MSBuild on the SqlProj file with the appropriate output directory. We don't specifically publish at that point, but instead publish the artifact to Octopus Deploy in our workflow which does the actual deployment.
Again, not sure it will help on Ubuntu, but thought the additional detail might be useful.
As an alternative, it is possible to achieve this with dotnet cli and sqlpackage as explained here using an MSBuild Sdk.
You basically have a database project. Let's call it "DatabaseProject".
You create a new project which is a .NET standard c# library that you can call "DatabaseProject.Build".
Then you can configure you DatabaseProject.Build.csproj as such:
<Project Sdk="MSBuild.Sdk.SqlProj/1.11.4">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Configurations>Debug;Release</Configurations>
</PropertyGroup>
<ItemGroup>
<Content Include="..\DatabaseProject\**\*.sql" />
<Content Remove="..\DatabaseProject\bin\*.sql" />
<Content Remove="..\DatabaseProject\**\*.PostDeployment.sql" />
<PostDeploy Include="..\DatabaseProject\**\*.PostDeployment.sql" />
</ItemGroup>
</Project>
Be Aware The version used V1.11.4 is the one that supports the current .NET SDK shipped with visual studio at the time of the edit of this post. Check out the github repo to get the latest nuget version for your projet.
Using dotnet build will generate a dacpac that you will be able to use with either dotnet publish or sqlpackage.
You can then publish to you SqlServer instance.
If you're like me using a linux runner in your CI, you'll probably need SqlServer authentification method and then run either
sqlpackage /Action:Publish \
/SourceFile:\"DatabaseProject.Build/bin/Debug/netstandard2.0/DatabaseProject.Build.dacpac\" \
/TargetServerName:MyDatabaseServerName \
/TargetDatabaseName:MyDatabaseName \
/TargetUser:Username\
/TargetPassword:Password
or using a profile generated by visual studio :
sqlpackage /Action:Publish /Profile:\"DatabaseProject/PublishProfile/MyProfile.publish.xml\" /SourceFile:\"DatabaseProject.Build/bin/Debug/netstandard2.0/DatabaseProject.Build.dacpac\"
or
dotnet publish /p:TargetServerName=MyServerName /p:TargetDatabaseName=MyDatabseName /p:TargetUser=<username> /p:TargetPassword=<password>
Azure Data Studio now has an extension that lets you build database projects (sqlproj) using the dotnet tool. The brains behind building the project lies in the SQL Server Tools package, which is where the extension gets the required "BuildDirectory" DLL and targets dependencies.
Though not documented, if you want to set this up completely headless outside of Azure Data Studio, you can follow their CLI guide, https://learn.microsoft.com/en-us/sql/azure-data-studio/extensions/sql-database-project-extension-build-from-command-line?view=sql-server-ver15, but instead extract the necessary files from the RHEL release in https://github.com/microsoft/sqltoolsservice/releases and then follow the rest of the extension's documentation. Here is a working Dockerfile that demonstrates the approach:
FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
RUN apt-get update \
&& apt-get install -y curl
# SSDT dlls and targets file used by Azure Data Studio Extension can be found in the SQL Tools Service project
RUN curl -sSL -o /tmp/sqltools.tar.gz https://github.com/microsoft/sqltoolsservice/releases/download/v3.0.0-release.181/Microsoft.SqlTools.ServiceLayer-rhel-x64-net6.0.tar.gz
# Extract files that are required per https://learn.microsoft.com/en-us/sql/azure-data-studio/extensions/sql-database-project-extension-build-from-command-line?view=sql-server-ver15
RUN mkdir /tmp/sqltools && tar -xzf /tmp/sqltools.tar.gz -C /tmp/sqltools && \
mkdir /app/BuildDirectory && cd /tmp/sqltools && cp \
Microsoft.Data.SqlClient.dll \
Microsoft.Data.Tools.Schema.Sql.dll \
Microsoft.Data.Tools.Schema.SqlTasks.targets \
Microsoft.Data.Tools.Schema.Tasks.Sql.dll \
Microsoft.Data.Tools.Utilities.dll \
Microsoft.SqlServer.Dac.dll \
Microsoft.SqlServer.Dac.Extensions.dll \
Microsoft.SqlServer.TransactSql.ScriptDom.dll \
Microsoft.SqlServer.Types.dll \
System.ComponentModel.Composition.dll \
System.IO.Packaging.dll \
/app/BuildDirectory && \
rm -r /tmp/sqltools
#dotnet build your-database-project.sqlproj /p:NetCoreBuild=true /p:NETCoreTargetsPath="/app/BuildDirectory"
The commented command at the end shows what you could run inside the container in the directory with your database project.
This can also then be combined with a container utilizing sqlpackage to implement a full dacpac build and publish automation toolset.
As mentioned, the easiest way to build DacPac file on a linux agent is done via MSBuild.Sdk.SqlProj
Go to your database project directory in parallel to .sqlproj file create a directory like DB.Build under it create DB.Build.csproj copy.pase the content as below
<Project Sdk="MSBuild.Sdk.SqlProj/1.1.0"> <!-- This will pull in the required tools and dependencies to build a .dacpac with .NET Core -->
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Content Include="..\src\DB\masterdata\**\*.sql" /> <!-- link in the new .csproj to the .sql scripts in your existing database project -->
</ItemGroup>
</Project>
After run you will see dacpac file appears under DB.Build/bin/Release/netstandard2.0/DB.Build.dacpac
Here's my build agent output (Ubuntu agent on Azure devops)
Starting: SQL DB build Release
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.187.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
/opt/hostedtoolcache/dotnet/dotnet build /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj -dl:CentralLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" --configuration Release /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=/home/vsts/work/1/recommender-service-cicd/DacPac/
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 51.72 ms for /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj.
Using package name RecommenderAPI.DB.Build and version 1.0.0
Using SQL Server version Sql150
Deleting existing file /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Writing model to /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
RecommenderAPI.DB.Build -> /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/bin/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.71
Finishing: SQL DB build Release
Note: Make sure to restore you NuGet packages in step prior to build
Things I've done, in order:
Downloaded and installed PostgreSQL server 9.5.7 64bit from entreprisedb.com, latest version for which oracle_fdw is available
Installed the other stuff (postGIS, Npgsql, pgAgent, etc), in 64bit variant where it gave me the choice, in the second part of the installation
Downloaded oracle_fdw-1.3.0-pg95-win64.zip from https://github.com/laurenz/oracle_fdw/releases/ and extracted all the files to where they are supposed to be, C:/Program Files/PostgreSQL/9.5/....
Ran the following command in pgAdmin:
CREATE EXTENSION oracle_fdw;
and I got the following error:
ERROR: could not load library "C:/Program Files/PostgreSQL/9.5/lib/oracle_fdw.dll": %1 is not a valid Win32 application.
Either the oracle_fdw.dll is corrupt, or it not all of your software (Oracle client?) is 64-bit.
You will need a 64-bit Oracle client installed. See the README:
Oracle client version 10.1 or better is required.
oracle_fdw can be built and used with Oracle Instant Client as well as with
Oracle Client and Server installations installed with Universal Installer.
Binaries compiled with Oracle Client 10 can be used with later client versions
without recompilation or relink.
(There are oracle_fdw binaries for PostgreSQL 9.6 as well.)
I am trying to connect mssql server to PHP 7.0.8 through MAMP. I have tried using freetds. On some blog people are saying to use pdo_dblib.so extension but it's not working.
Please guide me through the process of connection.
For those who still have this problem:
/Applications/MAMP/bin/php/php7.2.1/bin/pecl install sqlsrv pdo_sqlsrv
Edit php.ini:
extension=sqlsrv.so
extension=pdo_sqlsrv.so
If necessary, use brew install autoconf if you don't have it already.
While the answers posted by Vague Space and Pedro Santiago helped, I still think the answers are a bit lacking and incomplete… Or ask you to do too much. Honestly the official Microsoft instructions are overkill when they state you need to install their Docker image of SQL Server and such? C’mon… Most people just need the drivers installed to make a connection.
So here is my answer based on my experience installing the pdo_sqlsrv.so and sqlsrv.so modules in MAMP (version 5.2) but should work for most any MAMP version that supports some flavor of PHP 7.
Adjust the .bash_profile so MAMP’s binaries and libraries are a part of your $PATH settings.
First, adjust your .bash_profile so the MAMP stuff is in there; makes it easier to launch and work with MAMP specific binaries and ensures MAMP libraries are checked when doing things like installing new modules like this.
The way I like to do it is like this; set $MAMP_BIN and $MAMP_PHP variables like this and then rebuild the $PATH variables:
# MAMP stuff.
export MAMP_BIN="/Applications/MAMP/Library/bin";
export MAMP_PHP="/Applications/MAMP/bin/php/php7.2.10/bin";
# Final $PATH setting.
export PATH="/usr/local/bin:/usr/local/sbin:$MAMP_BIN:$MAMP_PHP:$PATH";
Save it and just log out of the Terminal session and back in, or just resource the .bash_profile like this:
source ~/.bash_profile
With that done, let’s install the core Microsoft ODBC binary stuff.
Install the Microsoft ODBC stuff.
Do this to install the core ODBC stuff on macOS; be sure to have Homebrew installed:
brew tap microsoft/SQLSRV-release https://github.com/Microsoft/homebrew-SQLSRV-release
brew update
brew install --no-sandbox msodbcsql17 SQLSRV-tools
Then when that’s done, go ahead and install the Unix ODBC stuff like this:
brew install unixodbc
Now install the actual PHP modules via PECL:
pecl install sqlsrv pdo_sqlsrv
With the modules installed, add them to the php.ini file in MAMP so PHP can recognize it. For PHP 7.2.10 on MAMP 5.x it should be located here:
/Applications/MAMP/bin/php/php7.2.10/conf/php.ini
And just add these config lines to the bottom of the file:
; Enable 'Microsoft Drivers for PHP for SQL Server' extension module
extension = sqlsrv.so
extension = pdo_sqlsrv.so
; Configuration
;sqlsrv.WarningsReturnAsErrors = 1
;sqlsrv.LogSeverity = 0
;sqlsrv.LogSubsystems = 0
;sqlsrv.ClientBufferMaxKBSize = 10240
;pdo_sqlsrv.log_severity = 0
;pdo_sqlsrv.client_buffer_max_kb_size = 10240
Note, most tutorials—and even PECL when you install the modules—simply mention adding extension = sqlsrv.so and extension = pdo_sqlsrv.so to the php.ini config, but these config options are the ones that RedHat has when installing the PHP SQLSRV via the Remi repo. Yeah, most of them are commented out but I still like having it there for reference.
Follow this guide through step 3: Microsoft PHP drivers for SQL Server
Find where pecl drops extensions in your local machine
Copy the files pdo_sqlsrv.so and sqlsrv.so into your MAMP's PHP extension directory. Mine was located at /Applications/MAMP/bin/php/php7x.x/lib/php/extensions/no-debug-foo-bar
Edit your php.ini file to include the new extensions:
extension=sqlsrv.so
extension=pdo_sqlsrv.so
Restart your MAMP servers.
having just done this in 2019 with MAMPPRO4 on windows 10 (follow upto step 4 to test that you are connected and then do point 9 ) point 5 onwards is for changing the path in the command line
download dll files from microsoft
https://www.microsoft.com/en-gb/download/details.aspx?id=20098
follow the instruction after running the exe file and place the dll
files into the extension directory of the php version that you are
using eg: MAMP/bin/php/php7.1.29/ext
check phpinfo for the Loaded Configuration File of the php.ini file
add the 2 dll files depending on your requirements (I wasted time by
using the 64.dll) make sure you are using ts(thread safe) not
nts(none thread safe) in the file name of the dll
extension=php_sqlsrv_71_ts_x86.dll
extension=php_pdo_sqlsrv_71_ts_x86.dll
in control panel search for advanced system settings and click
click Environment Variables
under system variables not user variables click path and click edit
click new and add C:\MAMP\bin\php\php7.1.29 (Edit this to your path)
restart MAMP
open a new command line an enter php -v
you should see the php version displayed
I would like to download and install the Oracle DataModeler
But im stuck at the window that says:
"please specify the path to the java jdk home:_________"
What do i do?
Help would be greatly appreciated
You tell it where Java is installed. SQL Developer Data Modeler is a java application and can't run without Java.
If you're on Windows, you can download the package that includes the JDK. If you're not on Windows, install Java 8 (JDK), and then run SQL Developer. If it doesn't see Java, it will ask for the path. Give it the path from your install.
When I installed Datamodeler, the first time I launched the software it asked me for a java path. On my machine this was /usr/lib/jvm/java-1.8.0-openjdk-amd64. If you are running on a linux distro, there should be an opt subdirectory with a configuration file that you can edit manually:
/opt/datamodeler/datamodeler/bin/datamodeler.conf
try changing the last line of the file from
SetJavaHome ../../jdk
to
SetJavaHome /path/to/your/java (whatever your java path is)
I'm still having issues -- but this might work for you.