I have a windows service that runs every 1 hour. I would like to store the last run date-time so that I can check the value (last run date-time) every time the service runs.
This value is used as one of the parameter for stored procedure used by the service to get data.
Now, my question is what is the best/ideal way of storing this last run date value?
I can think of 3 ways:
Store it in a database table.
Store it in a text or XML file in the application folder (question here is: is it good to create a text
file in application folder and update it every hour?).
Create a section in config file and update it every time service is executed.
Experts, please advise.
If you have a single service that needs to check the last time the process it executes was run to completion, I would store in as a user setting item. If you are thinking that maybe you'll have many services that share this task, putting it a shared location (like a database) would be helpful--although, it should be easy to migrate the data from user setting to a database should you need to use multiple services.
I would avoid a custom XML or data file simply because there's already support for user (run-time) settings in .NET and Visual Studio.
Update:
If you want to use user settings, you can simply double-click the Settings in Solution Explorer (under Properties in a Project) or in the properties for a Project, select the Settings tab. Add a value with a User Scope (probably of type System.DateTime. And if you named LastExecuted it you would use code like the following to update the value:
Properties.Settings.Default.LastExecuted = DateTime.Now;
Properties.Settings.Default.Save();
Related
I just started looking into Flyway using the command line route, and was wondering if it is possible to reuse the .sql file?
Example:
I have a file called V1__Create_user.sql which has
CREATE USER ${user_name} WITH PASSWORD '${pass}';
GRANT readaccess TO ${user_name};
It looks like I can only use this sql file once, that is when I run below command
flyway -placeholders.userName=test_user -placeholders.pass=test migrate
When I run the above command again with different user_name and password for the placeholders, no changes was made.
So, I was wondering if there's a way to reuse that sql file instead of generating new sql files containing the same sql query over and over ?
The way Flyway works is that it runs the scripts you provide it in the order in which you provide it. It puts a marker in the database showing which scripts it has already run. Then, when you rerun it, it will only run the scripts that it has not yet: run V2__Whatever, V2.2__Something, etc..
You can't go back & modify an existing script and expect the tool to pick up that it has changed and then rerun it. Even if that script is using placeholders.
That doesn't include the repeatable scripts (stuff like view definitions) that run every time you deploy using Flyway. If you had to, you could make that a repeatable script and run it that way. BUT, that will work as long as every deployment is incremental, 1 to 2, 2 to 3, 3 to 4. As soon as you need to deploy from version 1 to 4, you can't pass multiple commands in.
Since every instance of SQL in relational data stores I'm aware of is a declarative language, the best way to deal with it, is to use it as such. Yes, that means stuff like CREATE USER is used over & over. However, since each USER created is unique, that's just how it works.
I am developing UWP application using vs studio 2017 version 15.9.6.
I want to use Windows local SQLite database. I want to run an SQL script named mySql.txt when the user first time install the application. I dont want to run it every time when the user run the app as it contain insert statement, which will cause duplicate rows insertion. So I want to run that script only once, preferably in the installation time.
How can I do that? I am very new to UWP and .NET. Please guide me step-by-step if possible.
You can make sure the initialization/seeding is done only once for the app. For that you may utilize ApplicationDate.Current.LocalSettings.
These allow you to write simple data for your application which are bound to your app. Once the user uninstalls the app, these data will be removed as well. This fits your scenario exactly.
Suppose your database initialization code is in the method InitializeDb(). You could use the following to make sure the initialization is done only once:
if (!ApplicationData.Current.LocalSettings.Values.ContainsKey("DbInitialized"))
{
InitializeDb();
ApplicationData.Current.LocalSettings.Values["DbInitialized"] = true;
}
This code first checks if we have initialized the db previously and if not, performs the initialization and stores a flag into app settings to make sure the next time the initialization is skipped.
You can run this code during app initialization, for example in OnLaunched method, or on when the database service is first required.
This is of course the simplest implementation, so you can (and should) add some exception handling, so that if the initialization fails, it can be retried and so on. Also you may want to handle app updates and DB updates - in which case you can use ApplicationData.Current.Version which allows you to track the version of application data and can be used to keep track of DB version as well so you can perform appropriate migrations between versions.
Finally, for even better user convenience, there is also a way to perform the app update steps during updates. See this article for more info.
Context:
I have a (legacy) ASP.NET app using a class lib which's data access is calling SPs using ad dal.dbml and its generated code.
I am using VS 2015 Enterprise update 1, have locally installed Microsoft SQL Server 2014 - 12.0.4213.0 (X64) (Build 10586) and SSMS 2014.
Question
When running the Web application the app inserts rows to a table which I recently implemented an insert trigger. How can I debug the actual trigger execution "triggered" by the Web application?
Note: I do know how to interactively debug SPs in SSMS. Now that is not I want, because It is nearly impossible to reproduce and parametrize what the web app does. So I would like to debug via the Web App.
Is this possible at all? (Seems to be a pretty usual need, though I unserstand it requires very complex debugging infrastructure and services)
What you do is you run Profiler to get the typical values being sent when the error occurs.
Then the easiest way I know of to troubleshoot something like this is to take the trigger code out of the trigger and put it in a script using #inserted (and/or #deleted if need be) instead of the pseudotables accessed by the trigger.
The insert the data the stored proc would insert into the table into the #inserted table. Then you can take the trigger step by step and even look at the results of a select that is used in an insert.
The most common error I have found in triggers is that they are set up to handle only one record in inserted rather than multiple records. SO if you find that what your proc would put in for the values you get is one record, that may be the issue. Or you may be missing a required field. IN that case you may need adjust the proc to put in the value or assign a default.
We have a Qt app that when it starts tries to connect to a servlet to get config parameters that it needs to keep running.
The URL may change frequently because we have to test the application in several environments. Right now (as a temporary solution) the URL is a constant in source code, but it is a little bit ugly.
Where is the best place to mainting this URL, so that we do not need to change the source code every time I want to change the environment target?
In a database table maybe (my application uses a SQLite DB), in a settings file, or in some other way?
Thank you for you replies.
You have a number of options:
Hard coded (like you have already)
Run-time user input
Command line arguments
QSettings
Read from a bespoke file as text.
I would think option 3 would be the most simple to implement without being intrusive, but it does depend on what kind of application you have.
I would keep the list of url in a document, e.g. a XML, stored in a central, well known place, e.g. a known web server, and hardcode the url of the known place in the app.
The list could then be edited externally without recompiling your app;
The app would at startup download and parse the list, pointing to the right servlet based upon an environment specified as a command line parameter.
I would like to find a way to create and populate a database during asp.net setup.
So, what I'm willing to do is:
Create the database during the setup
Populate the database with some initial data (country codes or something like that)
Create the appropriate connection string in the configuration file
I'm using .NET 3.5 and Visual Studio 2005, and the Database is SQL Server 2005.
Thanks in advance.
If you are creating an installer I'm sure there is a way to do it in there, but I am not all that familiar with that.
Otherwise, what you might do is the following.
Add a application_start handler in the Global.asax, check for valid connection string, if it doesn't exist, continue to step two.
Login to the server using a default connection string
Execute the needed scripts to create the database and objects needed.
Update the web.config with the connection information
The key here is determining what the "default" connection string is. Possibly a second configuration value.
Generally, you'll need to have SQL scripts to do this. I tend to do this anyway, as it makes maintaining and versioning the database much easier in the long run.
The core idea is, upon running the setup program, you'll have a custom action to execute this script. The user executing your setup will need permissions to:
Create a database
Create tables and other database-level objects in the newly-created database
Populate data
Your scripts will take care of all of that, though. You'll have a CREATE DATABASE command, the appropriate CREATE SCHEMA, CREATE TABLE, CREATE VIEW, etc. commands, and then after the schema is built, the appropriate INSERT statements to populate the data.
I normally break this into multiple scripts, but YMMV:
Create schema script
"Common scripts" (one for the equivalent of aspnet_regsql for web projects, one with the creation of the Enterprise Library logging tables and procs)
Create stored procedure script, if necessary (to be executed after the schema's created)
Populate initial data script
For future maintenance, I create upgrade scripts where a single script typically handles the entire upgrade process.
When writing the scripts, be sure to use the appropriate safety checks (IF EXISTS, etc) before creating objects. And I tend to make mine transactional, as well.
Good luck!
Well, actually I found a tutorial on MSDN: Walkthrough: Using a Custom Action to Create a Database at Installation
I'll use that and see how it goes, thanks for your help guys, I'll let you know how it goes.
If you can use Linq to Sql then this is easy.
Just import your entire database into the Linq to Sql designer. This will create objects that describe all objects in your database, including the System.Data.Linq.DataContext derived class that encapsulate the entire database setup.
Now you can call DataContext.CreateDatabase() to create the database.
See here more information.