I already run MAMP as a local server environment for apache and MySQL, so when I installed Mac OS X Server, which runs it’s own instance of apache, my server encountered problems with MAMP which failed to start.
After some investigation I found the OS X Server instance of Apache started with the system resulting in MAMP failing to start, with no obvious setting to disable the in-built apache services in the OS X Server app settings.
Here’s how to prevent the service starting automatically, then kill the existing service:
Step 1: Locate the following file: /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf
Step 2: Comment out the listening ports in the file
Example using standard ports, change:
Step 1: Click on the Windows search bar or press the start key on your keyboard, type cleanup, then select Disk Cleanup.
Step 2: Click ‘Clean up System file’
Step 3: Scroll to, and select, Previous Windows Installations. Click start to begin the cleanup process which will include the removal of previous Windows installations from your disk.
This freed almost 30Gb on my disk. This, of course, means you’re unable to revert back to your previous Windows installation so proceed with that in mind. I found the disk space more valuable than holding on to the files.
This article describes how to remote view another Mac using Apple Screen Sharing. There is no need to run any third party software as it can all be done using apple’s built in Screen Sharing services, for free! I’m using OS X EL Capitan, Version 10.11.13.
There is just one catch; both devices must use the same iCloud account. If you’re looking to connect to a Mac using different iCloud account then VNC is a good option. For now, I’ll concentrate on connecting to another Mac logged in with the same iCloud account.
Step 1: Open System Preferences on the Mac you plan to connect to from another device. click the Apple icon in the top-right bar, then select System Preferences…
Step 2: Click the Sharing icon.
Step 3: Tick Screen Sharing in the Service list
Step 4 (Optional): That’s all the configuration required to access you Mac remotely if on the same WLAN/LAN. The following step is required if you plan to connect to your Mac from a separate network. Head back to System preferences then select iCloud.
Tick Back To My Mac.
Step 5: Head over to your other Mac device and open Finder. You should now see your remote Mac’s name under Shared devices. Click your device, then click Share Screen…
NOTE: If your remote Mac doesn’t appear in your Shared list, you may need to re-start Finder to scan for your device. (Apple Menu —> Force Quit… —> Select Finder and hit Relaunch)
The Share Screen button will Launch Apple’s built in Screen Sharing app allowing you to view and control your remote Mac.
You can right-click the Screen Sharing app icon from the dock while the app is running, then click Options, then Keep In Dock. This makes it easier to find the app in future. When the app is closed you can you can now right-click the app icon from the dock, then select your remote Mac to quickly connect.
SQL Server keeps a log of mail sent via Database Mail and the sp_send_dbmail Stored Procedure.
I find these code snippets useful to view mail history including sent and failed items. You can view address, subject & body, file attachment(s), status, sent date, etc.
All Messages – regardless of status and deliverability
SELECT top 50 *
ORDER BY [send_request_date] DESC
SELECT TOP 50 *
ORDER BY [send_request_date] DESC
SELECT TOP 50 *
ORDER BY [send_request_date] DESC
The EXECUTE permission was denied on the object ‘STORED_PROC’, database ‘MYDB’, schema ‘dbo’
This massage is received when the SQL Server account under which you make the request doesn’t have permission to execute the stored procedure. you can overcome this problem by modifying the permissions of the SP.
If you want to grant public access, so all users can execute the procedure:
GRANT EXEC ON dbo.[MYSTOREDPROCEDURE] TO PUBLIC
If you want to tighten security to allow only specific users to execute the SP, which is advisable, then its:
GRANT EXEC ON dbo.[MYSTOREDPROCEDURE] TO MYUSER
USE [DATABASE]; GRANT EXEC ON dbo.[MYSTOREDPROCEDURE] TO MYGROUP
This question comes up time and time again and there are two programs that I frequently use to build my compiled Java apps into a Windows Executable files. This, of course, limits the environments in which your app can run to Windows only devices, so if you plan to release a ‘Windows only’ version then this could be the solution for you.
It’s worth noting that it’s also possible to bundle a jar app into a Mac OSX specific .app file, which could be something to consider if you intend to release your app to Mac OS. The .app file extension provides Mac users with a familiar file name structure which can add a subtle level of authenticity to your app. I will cover building a jar file into a Mac OS .app file in a future post.
So back to Windows…
Option 1: JSmooth (Click here to download from SourceForge)
Smooth provides a basic and easy to use interface to build your jar file into an exe. JSmoth frequently uses relative file paths, so I tend to launch within the distribution file of my compiled Java app.
The app opens on the Welcome screen, which is pretty standard. You can navigate through the pages using the menu located at the left-hand side of the screen.
Head to the Executable section
Executable Binary: Enter the location and file name for the exe file you wish to output. I’ve chosen to save my output file as MYAPP.exe.
Executable Icon: Select and icon image file to be used in your exe file. I’ve chosen to use WORLD.png located in the source of my app.
Current Directory:Here you can specify the working directory, your safe to leave this blank unless you implicitly wish to set it.
Head to the Application section
Main Class: Enter the name of the main class in your Java app, that is the main initial class called at runtime.
Application Arguments: You can optionally enter arguments to be passed to your app at runtime. You can enter multiple arguments separated by a comma.
Embedded Jar: Tick the option to Use an embedded jar and specify the name of your compiled Java .jar file. This tells JSmooth the location from which to load your .jar file.
Classpath: Here you must enter every external library (.jar file) included in your app. My compiled Java app has my libraries contained in a LIB folder in the same directory as my MYAPP.jar file.
IMPORTANT! The library paths are relative to your jar file AND your exe. In my example, MYAPP.exe MUST launch from a file location containing the LIB folder holding the libraries.
Head to JVM Selection
Minimum JVM Version: If your app requires a specific JVM version or higher, specify here.
Maximum JVM Version: If you wish to limit your app to run below a certain JVM, specify here.
Bundle JRE with your app – OPTIONAL You can optionally include a bundled Java Runtime Environment with your exe. This enables your app to run an a PC that doesn’t already have a Java installation. It also gives you control over which JVM version gets used to run your app. If the PC already has a JVM installed then your exe will use the bundled version instead of the PC version. Leave this blank to default to the installed JRE.
Tick Use a JVM bundled with your applicationSpecify a file location, relative to your exe, which contains a full JVM.In my example, I have a folder named JRE_MASTER which contains a full JVM.
NOTE: You may bundle a 32-BIT JVM with your exe for operation on 64-BIT OS. This could be useful if your app contains 32-BIT libraries.
Go ahead and hit the COG icon at the top of the screen. All being well, you should now have a .exe file bundled from your compile .jar file.
Smooth error messages are usually detailed enough to help locate and fix potential problems.
Option 2: Launch4j (Click here to download from SourceForge)
Launch4J is set out using a tabbed menu located at the top of the screen, opening on the Basic tab. I will describe some of the basic functions required to generate an exe and once familiar with the process you can explore the advanced functions.
Output File: Enter the location and file name for the exe file you wish to output. I’ve chosen to save my output file as MYAPP.exe.
Jar: Specify the name of your compiled Java .jar file. This tells Launch4J the location from which to load your .jar file.
Icon: Select and icon image file to be used in your exe file. I’ve chosen to use WORLD.ico.
Bundle JRE with your app – OPTIONALYou can optionally include a bundled Java Runtime Environment with your exe. This enables your app to run an a PC that doesn’t already have a Java installation. It also gives you control over which JVM version gets used to run your app. If the PC already has a JVM installed then your exe will use the bundled version instead of the PC version. Leave this blank to default to the installed JRE.
Bundled JRE Path: Specify a file location, relative to your exe, which contains a full JRE.
Min JRE Version: If your app requires a specific JRE version or higher, specify here.
Max JRE Version: If you wish to limit your app to run below a certain JRE, specify here
Launch4j provides the ability to specify a splash screen, this feature is not available in JSmooth.
Tick Enable splash screen
Splash File:Specify as location of your launch image
Tick Wait for window
Timeout [s]: Enter a timeout period in which the splash screen will disappear
Click the COG icon to generate your exe file.
IMPORTANT!: The library paths are relative to your exe. In my example, MYAPP.exe MUST launch from a file location containing the LIB folder holding the libraries. You are not required to implicitly mention each library whilst configuring your exe, as you are with JSmooth.
You should now have a runnable exe file bundled from your compile .jar file. Take some time to explore the advanced functions within the configuration menus.
Once you’re happy with your configuration you may save the settings in XML, i.e. MYAPP.XML.
You can call Launch4j from command line, specifying the XML file as follows: