Steps to reproduce.
List the existing instances:
> sqllocaldb info
v11.0
Stop the instance with the specified name:
> sqllocaldb stop "v11.0"
Stop of LocalDB instance "v11.0" failed because of the following error:
The specified LocalDB instance does not exist.
The results are contradictory. How can it exist in the first command and then not exist in the second?
Try using
sqllocaldb stop v11.0
without quotes. It should work.
Are you using Visual Studio Tools? If not, try using it.
EDIT:
It also works if you user an admin command prompt and type:
cmd.exe /C sqllocaldb p "v11.0"
I know this is old, but since I stumbled upon it, I will add this answer in addition to Tiago Cachinho's.
The command sqllocaldb info will also show stopped instances. Try adding the name of the instance to get more information:
>sqllocaldb info v11.0
Name: v11.0
Version: 11.0.7001.0
Shared name:
Owner: me
Auto-create: Yes
State: Stopped
Last start time: 1/25/2020 3:40:46 PM
Instance pipe name:
Related
I get an appcrash when attempting to install arangoDB in on a windows 7 machine. I have also tried the XCOPY version and have the same issue. The APPCRASH gives the following:
Problem signature:
Problem Event Name: APPCRASH
Application Name: arangod.exe
Application Version: 0.0.0.0
Application Timestamp: 59704d12
Fault Module Name: arangod.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 59704d12
Exception Code: c000001d
Exception Offset: 0000000000200f77
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 2057
Additional Information 1: caa2
Additional Information 2: caa2bb545c0b7fee68e5ff27d1b7f78d
Additional Information 3: 95f8
Additional Information 4: 95f82d1cb337322ec0f22184a0acdc62
I do not believe it even attempts to access the arangod.conf file let alone object to something inside it.
I used Windows debugger to try and get some additional clues but I'm left stumped. The results are here: http://textuploader.com/do6wn
Please use github issues for these kind of problems.
I've been using my SQL database initialization script for a while, but it seems that recently the database crashes in the middle of the execution and I don't know why, but here's some details:
I am running OrientDB on Ubuntu 14 Trusty x64 (via Vagrant)
It always seems to crash while the script attempts to create a UNIQUE_HASH_INDEX, but doesn't always crash at the same UNIQUE_HASH_INDEX instruction
The script creates a lot of vertices and edges, but for example, it will crash here (see line with UNIQUE_HASH_INDEX):
CREATE CLASS Channel EXTENDS V;
CREATE PROPERTY Channel.version LONG;
CREATE PROPERTY Channel.channelId STRING;
CREATE INDEX Channel.uq_channelId ON Channel(channelId) UNIQUE_HASH_INDEX;
The database crashes entirely with the following error:
Creating index... Error:
com.orientechnologies.orient.core.exception.OStorageException: Error
on executing command: sql.create INDEX Channel.uq_channelId ON
Channel(channelId) UNIQUE_HASH_INDEX
Error: java.io.EOFException
Looking at the log files, the only hint I get are the last two lines:
2016-01-14 17:17:05:437 INFO Received signal: SIGTERM [OSignalHandler]
2016-01-14 17:17:05:454 INFO Received signal: SIGTERM [OSignalHandler]
How can I resolve this issue, or at least get better hints as to what is making the database crash?
I also test with OrientDB 2.1.6, as I was running the older version initially. Same problem.
Sorry, false alarm -- this is a Vagrant issue, not an OrientDB issue. Running the exact same script on a 32bit instance instead of 64bit solved my problem, and installing the same script on a real 64bit server also works.
I am new in firebird and I would like to trace my firebird-database activities, hence I am trying to use Audit/Trace Services.
My firbird databse is on Server: 10.7.105.8
I am running this comman in my cmd:
C:\Program Files\Firebird\Firebird_2_5\bin>fbtracemgr -se 10.7.105.8:3050:service_mgr -user SYSDBA -password masterkey -start -name "User Trace 1" -config "fbtrace.conf" > C:\Users\Babak\Desktop\trace.out
but I get this error:
Can not attach to service manager
Service 3050 : Service_mgr is not defined
What should I do to solve this problem?
thank you so much
EDIT
thank you for your hints. I think my trace process works fine, but I cant find the information, what I need in my trace.out file
If I am starting my trace my command promp looks like this:
if in this step I take a look in my trace.out I can only see this:
Trace Session ID 3 Started
I am running some select queries in my firebird, and then I finish my trace with with ctr+c, then the only things, which I can see in my trace.out are something like this:
Trace session ID 3 started
2015-07-08 10:49:59.868874 ***** loading fbclient.dll proc=4116 64Bit DLL Preload
2015-07-08 10:49:59.869066 GetDllDirectoryA=""
2015-07-08 10:49:59.869075 GetModuleFileNameA="C:\Program Files\Firebird\Firebird_2_5\bin\fbclient.dll"
2015-07-08 10:49:59.869086 Log-Level is set to 0
2015-07-08 10:49:59.869096 fbclient.dll loaded by: C:\Program Files\Firebird\Firebird_2_5\bin\fbtracemgr.exe
2015-07-08 10:49:59.869113 ***** dimensio integration successfully fbclient.dll
2015-07-08 10:58:10.091330 ***** cleanup unload fbclientorg.dll proc=4116
and not more infos about queries, which I have run.
Could you please say me, what I have done wrong? or what should I do more?
As Mark says, check file "fbtrace.conf". This is a text file and you will see something like this:
# default database section
#
<database>
# Do we trace database events or not
enabled false
# Operations log file name. For use by system audit trace only
#log_filename
....
....
# Put transaction start/end records
log_transactions false <--- TO TEST, SET THIS TO TRUE
# Put sql statement prepare records
log_statement_prepare false <-- TO TEST, SET THIS TO TRUE
Set to true what you need to trace, save the file and check the result.
Firebird connection strings are of the format:
host/port:database
Where /port is optional and defaults to 3050, and database is either the alias or path of a database, or the name of a service. Replace :3050 with /3050 (or leave it off entirely).
The following worked for me:
Open start menu
Search for services and open it
Search Firebird Guardian in the services list.
Start Firebird Guardian if it is stopped or restart if it is running.
Now try to connect your server. It will work.
The issue occurs when executing EF 6.1.2 code first migrations in an Azure Web Role (WS 2012 R2). The same migrations run fine locally, even if I point the connection string to the (Azure) Sql Database.
The StackOverflowException is thrown by Entity Framework code, and the first line of ANY of my migrations doesn´t even get hit.
I have tried running the migrations in three different ways:
DbMigrator migrator = new DbMigrator(configuration);
migrator.Update(); // Here the exception is thrown
second:
DbMigrator migrator = new DbMigrator(configuration);
pendingMigrations = migrator.GetPendingMigrations().ToList();
foreach (string pendingMigration in pendingMigrations)
{
migrator.Update(pendingMigration); // Here the exception is thrown
}
and using web.config:
<contexts>
<context type="Superb.WorkNextDoor.EFRepository.Context.WndDbContext, Superb.WorkNextDoor.EFRepository, Version=1.0.0.0, Culture=neutral">
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[Superb.WorkNextDoor.EFRepository.Context.WndDbContext, Superb.WorkNextDoor.EFRepository], [Superb.WorkNextDoor.EFRepository.Migrations.Migrations.WndDbMigrationsConfiguration, Superb.WorkNextDoor.EFRepository.Migrations]], EntityFramework">
</databaseInitializer>
</context>
</contexts>
I see the StackOverflowException in Visual Studio when I´m remote debugging the web role. An error is recorded in windows event log of the web role (log info at the bottom of this post).
I have two migrations. I have tried running the first one from PMC and the second from the web role but no luck.
I have tried installing .Net 4.5.2 on the server, changing the VM size from XS to S and downgrading EF to version 6.1.1. Nothing worked. Also, I tried downloading the folder "E:\sites\0" from the web role to my local computer, installed the app on IIS and attached my VS Debugger and it doesn't throw that exception. There has got to be something different between my Windows 8.1 and that Windows Server 2012 R2.
I have spent a lot of time trying different things but I don´t want to give up on this and have to execute my migrations from package manager console.
Log Name: Application Source: Application Error Date:
1/11/2015 3:21:42 AM Event ID: 1000 Task Category: (100) Level:
Error Keywords: Classic User: N/A Computer:
RD0003FF508F5B Description: Faulting application name: w3wp.exe,
version: 8.5.9600.16384, time stamp: 0x5215df96 Faulting module name:
clr.dll, version: 4.0.30319.34014, time stamp: 0x52e0b86c Exception
code: 0xc00000fd Fault offset: 0x0000000000195499 Faulting process id:
0xc60 Faulting application start time: 0x01d02d4d77fdfb93 Faulting
application path: d:\windows\system32\inetsrv\w3wp.exe Faulting module
path: D:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Report
Id: f5e4d6dc-9940-11e4-80bd-0003ff508f5b Faulting package full name:
Faulting package-relative application ID: Event Xml:
1000
2
100
0x80000000000000
467
Application
RD0003FF508F5B
w3wp.exe
8.5.9600.16384
5215df96
clr.dll
4.0.30319.34014
52e0b86c
c00000fd
0000000000195499
c60
01d02d4d77fdfb93
d:\windows\system32\inetsrv\w3wp.exe
D:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
f5e4d6dc-9940-11e4-80bd-0003ff508f5b
Easy steps to reproduce this error:
Download this sample project: http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application
Add a CloudServiceProject to the solution and add the web project as a web role
Publish it to azure
Browse the web site and go to students tab (this hits the database and the initializer tries to execute the migrations).
Happens the same.
This is identified as a bug in Microsoft Visual Studio 2013 Update 4. As a temporary work around disable "Lazy Initialization" under IntelliTrace Settings -> IntelliTrace Events. We are investigating fixing this bug in a future update for Visual Studio 2013.
The responsible for the StackOverflowException turned out to be IntelliTrace. I don't know the root cause of the issue between IntelliTrace and Code First Migrations that cause this behavior but when I downloaded the IntelliTrace logs I could see a lot of Sql exceptions:
I have already lost a lot of time with this so I won't investigate it further. The easiest workaround for me now is just disable IntelliTrace before deploying my Web Roles:
If somebody is curious, here are the IntelliTrace logs.
I hope this helps someone else solve such a problem without losing as much time as I did.
Environment:
Glassfish 4.0 (only one DAS), Windows Server 2012 R2, Java 1.7.0_51
Create the DAS instance service by using the create-service subcommand.
Issue:
The maximum history files attribute has been set, however, Glassfish Server couldn’t remove the old log files due to the lock file server.log.lck
Path --> C:\glassfish4\glassfish\domains\domain1\config\logging.properties
com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=10
Log Snippet:
[2014-12-10T18:00:39.372+0900] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=16 _ThreadName=Thread-5] [timeMillis: 1418202039372] [levelValue: 1000] [[
java.util.logging.ErrorManager: 0: FATAL ERROR: COULD NOT DELETE LOG FILE.]]
[2014-12-10T18:00:39.372+0900] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=16 _ThreadName=Thread-5] [timeMillis: 1418202039372] [levelValue: 1000] [[
java.io.IOException: Could not delete log file: C:\glassfish4\glassfish\domains\domain1\logs\server.log.lck
at com.sun.enterprise.server.logging.GFFileHandler.cleanUpHistoryLogFiles(GFFileHandler.java:725)
at com.sun.enterprise.server.logging.GFFileHandler$4.run(GFFileHandler.java:802)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.server.logging.GFFileHandler.rotate(GFFileHandler.java:744)
at com.sun.enterprise.server.logging.GFFileHandler$1.run(GFFileHandler.java:301)
at com.sun.enterprise.server.logging.LogRotationTimerTask.run(LogRotationTimerTask.java:68)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)]]
Findings:
1, If the lock file “server.log.lck” exists in the log folder, the issue occurred, and can find the above errors in the log every day when Glassfish server tries to remove the old log files. If there is no “server.log.lck” in the log folder, no any issue and work properly.
2, If the DAS instance is started by the command “asadmin start-domain domain1”, there is no lock file “server.log.lck” generated in the log folder. But if the DAS instance is started in Windows Service, the lock file “server.log.lck” will be generated automatically and keep 0KB until stop the service, this file will be removed automatically.
3, If the DAS instance is started by the command “asadmin start-domain -w domain1” which adds the watchdog option, the lock file “server.log.lck” will be generated automatically and exist until stop the service.
4, When the lock file “server.log.lck” appears, there is always one more java.exe process existing. Therefore, when start the DAS instance from Windows Service, there are two “java.exe” running in the process and “server.log.lck” is using by one of them.
Questions:
1, I’d like to start/stop the DAS instance by Windows Service, not using the subcommand. Moreover, I don’t want to keep all Glassfish logs on my server and it will cause a disk full issue so that I would prefer to turn on the Glassfish Logging Maximum history Files option. Is there any workaround or solution for that?
2, Is this a defect of Glassfish or it’s just a setting issue? I did try to install on other servers and all had the same issue.
3, Why there are two java.exe processes running if started from Windows Server, is the 2nd one used for “watchdog”?
Thank you so much for your help and please let me know if there is any further information you’d like to know or want me to do some other tests.
In case someone is still struggling I found a solution.
When you create a GF service in Windows environment via asadmin create-service GF creates a file domain1Service.xml in glassfish\domains\domain1\bin which contains parametres for server to start.
It looks something like the following
<service>
<id>domain1</id>
<name>domain1 GlassFish Server</name>
<description>GlassFish Server</description>
<executable>C:/Supertel-NMSv3/glassfish-4.1/glassfish/lib/nadmin.bat</executable>
<logpath>C:\\Supertel-NMSv3\\glassfish-4.1\\glassfish\\domains/domain1/bin</logpath>
<logmode>reset</logmode>
<depend>tcpip</depend>
<startargument>start-domain</startargument>
<startargument>--watchdog</startargument>
<startargument>--domaindir</startargument>
<startargument>C:\\Supertel-NMSv3\\glassfish-4.1\\glassfish\\domains</startargument>
<startargument>domain1</startargument>
<stopargument>stop-domain</stopargument>
<stopargument>--domaindir</stopargument>
<stopargument>C:\\Supertel-NMSv3\\glassfish-4.1\\glassfish\\domains</stopargument>
<stopargument>domain1</stopargument>
</service>
the line <startargument>--watchdog</startargument> is responsible for launching watchdog process which prevents log file from being deleted.
You can't just delete this startargument section (the service won't start) but you can switch this off by setting false flag like this
<startargument>--watchdog=false</startargument>
After that the service will start like via manual start-domain command without watchdog process.
You should do it after every service creation and it could be pretty annoying so I did further research.
It turns out that asadmin create OS specific domainService.xml by using templates located in glassfish\lib\install\templates Those templates also OS specific. And template for Windows (named Domain-service-winsw.xml.template) looks like this
<service>
<id>%%%NAME%%%</id>
<name>%%%DISPLAY_NAME%%%</name>
<description>GlassFish Server</description>
<executable>%%%AS_ADMIN_PATH%%%</executable>
<logpath>%%%LOCATION%%%/%%%ENTITY_NAME%%%/bin</logpath>
<logmode>reset</logmode>
<depend>tcpip</depend>
<startargument>%%%START_COMMAND%%%</startargument>
<startargument>--watchdog</startargument>
%%%CREDENTIALS_START%%%%%%LOCATION_ARGS_START%%%<startargument>%%%ENTITY_NAME%%%</startargument>
<stopargument>%%%STOP_COMMAND%%%</stopargument>
%%%CREDENTIALS_STOP%%%%%%LOCATION_ARGS_STOP%%%<stopargument>%%%ENTITY_NAME%%%</stopargument>
</service>
So you can edit template directly by setting param --watchdog=false and this change will reflect in all future created files domainService.xml
Hope it helps.
That’s not the right solution. Watchdog has an important function: it monitors whether the service is running or not. Without watchdog, glassfish is started correctly, but shortly afterwards the system no longer knows if the service is still running or maybe crashed. In the Services GUI, only the “start” button is active (always!). A “stop” and “restart” cannot be used.
A right solution would be the possibility to change the path to the lock file.