As a personal project I want to test the ability of using SQLite with MVC 3 and so far so good managed to get everything setup.
The thing I am now trying to achieve is to make the solution fully portable during development, but I am unable to achieve this as the connection string is complaining that the database is missing if I try on different machines where the solution it located in different places.
Is there any way that I can alter the connection string so it is uses a set directory each and everytime?
I have the database housed in a datalayer solution in the same folder houses my datamodel if that is any help
I see two ways:
Specify the location of the SQLite database as relative to the executable
Make the path specifiable as input (say a command line argument or .config file)
Related
I am new in Xamarin and trying to make a simple project. I already make a small CRUD project with SQLite local database. I have two questions :
In which folder (path) in my computer the database is created ? Below is my DB path. But I am unable to find my database in my computer (Actually I want to know the folder path where is database created)
string DBPath=Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal), "myDB.db3");
My 2nd question is, I want to get data from same database (myDB.db3) from two different project. How can I do it using Xamarin?
I google a lot but do not get any proper answer. Please help.
Thanks in Advance.
Usually it is the home directory of the user (e.g. /Users/kay on macOS). Use Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.Personal)); to see where the file is stored on which platform.
Put the db file within a folder of your shared project. Then you can use *Add / Add Exisiting Item to link this file to your platform specific projects like MyApp.iOS/Resources or MyApp.Android/Assets.
I'd like to know what is the best practice to connect to H2 database when using embedded mode, e.g. in standalone Java desktop application.
Currently, I have the database file (.h2) in the same directory as main application jar file and using standard jdbc:h2:file: prefix to locate the file on the disc. Of course, this can be portable only if you can get the absolute path of the file dynamically, i.e. as relative path to the main Jar.
I am using this:
class.getProtectionDomain().getCodeSource().getLocation().getPath()
and its working. But I am not sure if its completely portable. I didn't try it on all the OS that Java supports.
Is there any other (maybe better) way to do this?
Regards,
Lubos
I have an Asp.NET MVC site that I manage multiple instances of. Each instance uses it's own database but the code base is all the same. To facilitate this I have several build configurations with matching web.config transforms, so that when I publish it doesn't use my development database but instead uses the specific database for that site instance.
The problem with this came today when I went to publish an update to one of the sites. I forgot to change the build configuration, so my publish to site A was using a web.config transform that was meant for site B, and mayhem and confusion ensued.
Is there any way to to specify that a specific publish target will ONLY be used with a specific build configuration?
Or is there a better way to handle this situation than juggling build configurations?
One way to deal with this sort of thing, and I'm not certain it's the best, but it is a way, is to set certain configuration values in a higher level web.config or machine.config file that always resides on the machine in question.
Then just make sure that your project files don't override those configuration values.
Here are some considerations if you do this.
If you want to source control these values, it can be more difficult
this way (this could be a pro or a con depending on your
environment).
If other virtual sites are on the same machine and use the same
configuration values, this could affect them all, and if multiple
sites do use that same configuration value, changing it at the
source will change them all (again, could be a pro or a con
depending).
If something is wrong with the value, it can be harder to
determine where the problem is or what is causing it.
Getting to machine.config may be difficult in your organization
or with your hosting provider depending on your access/security
privileges, and it's not always possible to put a web.config at a
higher level than your application.
Obviously the good thing here is that you can have a different value configured on each machine and as long as these values are not also set in your web.config (which would probably result in an error), you won't have to worry about compiling different versions.
I believe that Visual Studio 2010 has a way for setting different config files for different build types, but that sounds pretty much like what you are already doing, so forgetting to build the right way can still end up with similar results.
You could attempt to set up continuous integration with something like TFS Build if that is available to you, in which case what gets built for prod could be set up to always work a certain way and always pull from the correct build type.
Hope something here helps.
Maybe you could go a solution where you don't rely on the 'Publish' dialog of the web application that requires you to make the right setting every time, but instead use a automated command-line like solution (batch file, your own msbuild target, or a build server like CStroliaDavis suggested [cruisecontrol, tfs, teamcity]).
You can just call the 'package' target from command line which creates a package:
msbuild MyWebProject.csproj /t:Package /P:Configuration=Release;DeployIisAppPath="Default Web Site/Main/MyWebProject";PackageLocation="F:\MyWebProjectDeploy.zip"
This also creates a *.cmd file so you can deploy it like this:
F:\MyWebProjectDeploy.deploy.cmd /Y -allowUntrusted /M:http://webserver/MSDeployAgentService /U:Administrator /P:"Secret"
You can add a custom *.msbuild file to your solution that performs these actions, or maybe it's easiest to just add a command to Tools -> External tools.
With kwateeSDCM you can not just deploy apps and web applications but you can also manage instance-by-instance parameters or file overrides. I've only used it with tomcat wars but it's not tied to a language or a platform so I suppose it should be straightforward to configure it to work with ASP.NET as well.
I'm attempting to open some database files used by a legacy application that I know almost nothing about. The databases appear to be in file pairs of a bin and idx, for example: Cust.bin and Cust.idx.
I have never seen this type of database before and wasn't able to find anything useful through Google. I also don't know what language or tool the developer used for this app, but it seems that he used the default generic icon for his published executable. This is it:
Can anyone tell me anything about this application, what type of database it uses and how I might open the database myself?
The program that was using this database was a custom written application by a former consultant.
I never did figure out what type of database he was using, or how to open it properly. But I did manage to extract all the data out of it. I opened the file up in EditPad and found that all records had fixed-length fields. With this knowledge I was able to easily write a small application to parse all the binary data and export everything to .csv
So I was ultimately able to get the data. Woot!
Simple question... I have a VS 2005 solution that encompasses several reporting services projects. Currently, each project has it's own shared data source making changing the database target very tedious.
Is there a way to share the data source across the entire solution (i.e. all the projects in the solution will use the data source defined in one place?).
I thought I could create a project that just held one data source item and then make all of the other projects dependent upon that one, however, the shared date source in the new project does not appear in the other projects for me to select.
Help! I have looked around the web for info, but not much available. There must be a simple solution to this.
Thanks
I am sorry I somehow overlooked your question when I posted the same.
Nonetheless, a technique I am using is described in an answer to it. It feels a little shady and underhanded but seems to be working so far:
Make a new report project to hold your shared data source. I called mine Data Source.
Copy your shared data source (let's pretend it's called My Shared Data Source) to that new project.
If necessary, copy My Shared Data Source to each actual report project and link things up the way you want. But probably you're already set up like this.
Close Visual Studio to make sure all changes are saved in the filesystem and to make sure it doesn't end up clobbering some of our next, "backstage" edits.
In plain old Windows Explorer (or whatever), delete the My Shared Data Source.rds file from every project folder except Data Source's.
Using a text editor or XML-file editor, edit each project's .rptproj file to change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Source\My Shared Data Source.rds.
Now each project still has its own reference to a data source, but all those references happen point to the same underlying physical file, and thus they all share one data source specification.
According to this post by Paul Turley, it appears as if this is not possible. You'll have to copy the data source into each project. The good news is that if you deploy them to the same location, only one data source should exist on the server.
This may not be what you're thinking, but when I'm writing an app consisting of several distinct applicaitons accessing the same data I usually take one of two approaches.
write all of my data access logic into a Class Library project and reference it from the other projects.
Write my data access logic into a Web Service library and add a web reference.
I usually go for option 2 if the data I am accessing is likely to be used in future development, such as accessing company-wide customer lists, etc.