Animalstalking.com is a place where pets can go to meet new pet friends and keep in touch.
Recently a new group of App store developers has banded together to help push the cause of making the Apple App Store a little more developer friendly for people trying to make a living as Developers of applications for Mac’s and iPhones.
The website is called The Developers Union and has some listed goals and targets. Their about page states
We believe that people who create great software should be able to make a living doing it. So we created The Developers Union to advocate for sustainability in the App Store.
Today, we are asking Apple to publicly commit — by the tenth anniversary of the App Store this July — to allowing free trials for all apps in the App Stores before July 2019. After that, we’ll start advocating for a more reasonable revenue cut and other community-driven, developer-friendly changes.
Here is why we joined.
1. The stated goal of offering free trials is something what has reared it’s head for the looming release of our next app. “NOTAM Reader”. The model we wish to operate under is not currently available where we can offer a free trial. So their first stated goal is something we are defiantly onboard with and hope they can influence Apple.
2. The possibility of reducing the 70/30% split that developers share with Apple is something we also support. Apple the entire ecosystem and for that we are always grateful of the opportunity to develop on such a popular and solid ecosystem. BUT. They are so hugely successful throughout the entire process that it is hard not to feel that the wealth distribution is a little out of kilter. This is not something we are militant about but certainly a review of this policy is something we feel is worthy of banding tougher.
In the future we will review the groups stated goals and only remain part of the group while the stated goals are not self destructive and the process remains respectful for everyone involved.
Exception information: Exception type: ConfigurationErrorsException Exception message: Unsecured Passwords Format Detected. The Membership Provider that contains the unsecure passwords format is: AspNetSqlMembershipProvider. The obsoleted password format is: Encrypted. For more information, see https://go.microsoft.com/fwlink/?linkid=834784.
Request information: Request URL: Request path: User host address: User: Is authenticated: False Authentication Type: Thread account name: IIS APPPOOL\DefaultAppPool
We tried to connect the website up to the wrong database. i.e. When we copied the database and moved it, we inadvertently copied the wrong database. This caused the above error due to the fact that the machinekey data in the web.config file was wrong for the database.
This caused the error 1310 to be thrown and the Application Pool associated with the new incorrectly setup site to stop.
Connect to the correct database!
Further to this we encountered a really weird set of errors after this. Initially the error appears to be a connection issue. But then we started getting failings that would come an go.
Error logs showing plenty of Event ID 1310 but also in the DNN logs:
DotNetNuke.Services.Log.EventLog.DBLoggingProvider – System.Data.SqlClient.SqlException (0x80131904): Could not allocate space for object ‘dbo.EventLog’.’PK_EventLogMaster’ in database ‘bla’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at PetaPoco.Database.ExecuteScalar[T](String sql, Object args)
at DotNetNuke.Data.PetaPoco.PetaPocoHelper.ExecuteScalar[T](String connectionString, CommandType type, String sql, Object args)
at DotNetNuke.Data.SqlDataProvider.ExecuteScalar[T](String procedureName, Object commandParameters)
at DotNetNuke.Data.DataProvider.AddLog(String logGUID, String logTypeKey, Int32 logUserID, String logUserName, Int32 logPortalID, String logPortalName, DateTime logCreateDate, String logServerName, String logProperties, Int32 logConfigID, ExceptionInfo exception, Boolean notificationActive)
at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.WriteLog(LogQueueItem logQueueItem)
The issue turned out to be that the database was a legacy database we received from another host. They had defined a database limit size in the SQL database it’s self. This caused the database to strop responding to DNN in a way we had never seen. After some time, the maintenance would drop the size of the database just below the limit and the DNN site would fire up. Until it reached the SQL database limit again.
Not likely to be a problem for many people, but something to check in the SQL dates settings.
Increase or remove the size of the SQL database limit.
Skip to end of metadata
Go to start of metadata
Whenever a new application pool is created, IIS creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name “Smartcrypt,” a security identifier with the name “Smartcrypt” is created in Windows. Resources can be secured by using this identity. However, the identity is not a real user account and will not show up as a user in the Windows User Management Console.
This can be configured by selecting a folder in Windows Explorer and adding the “Smartcrypt” identity to the folder’s Access Control List (ACL).
By doing this, the file or directory you selected will now also allow the Smartcrypt identity access.
You can do this via the command-line by using the ICACLS tool. The following example gives modify access to the Smartcrypt identity to the folder C:\web\mds and all contents.
ICACLS "C:\web\mds" /grant "IIS AppPool\Smartcrypt":M /t