I created and deployed a split access database in Windows Server 2008 R2 Standard, however every time a user opens the front end file it opens the temporary file that locks the backend as well - defeating the purpose of splitting the database in the first place. Anyone else have issues with this? The backend file is never actually opened - it should just be relaying information to the frontend file...
This was tested in a folder that allowed full permissions for all users.
Related
I have a local GeoServer running on tomcat which using a PostGIS store to get layers from the PostgreSQL database. There is a production server that runs the same version of my local GeoServer and PostgreSQL database. In order to apply changes in layers and layer groups of my local GeoServer, I copied and replaced the data directory to production GeoServer. After restarting the tomcat on the production server, Geoserver unable to load Layers and Layer Preview pages on the web interface. Trying to change the host address of the store or creating a new one, it gives me this error:
Error creating data store with the provided parameters: Failed to upgrade lock from read to write state, please re-try the configuration operation
You don't say which OS you are using or how you made the copy, but the most likely error is a permissions or ownership one.
Make sure that the user which is running GeoServer has permission to read, write and execute on the data dir. On linux machines I've seen issues with uid and gid differences between machines depending on how the copy id carried out. On Windows I've seen issues just because windows and the virus scanner feel like it.
When using the community function jdbcconfig, the same issues.
It seems that an error occurs because file locking of catalog is performed.
Since the data directory is not used by using JDBCconfig, the file lock has been improved by setting it to Lock Disable.
https://docs.geoserver.org/stable/en/user/configuration/globalsettings.html#file-locking
I am trying to import data from an Access 2003 mdb database using OpenDataSource with the ACE OLEDB driver. I'm getting this error:
Description: OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Cannot start your application. The workgroup information file is missing or opened exclusively by another user.".
I have no idea what it's talking about, and my internet searches have not helped. They all refer to linked servers, and anything I've tried has done nothing to fix the problem. What does this error mean, and what do I need to do to fix it?
The sproc which does the importing is called from an SSIS package, which goes through a table of file locations and calls the sproc for each of them. I just discovered that the package ran for about half an hour, getting about 80 files imported, before it began throwing this error. I have as yet been unable to find any difference between the files that worked and the ones that didn't.
From Understanding the role of workgroup information files in Access security:
The workgroup information file is a required component when you use a
Microsoft Access database (MDB). This file is required for both a
run-time installation and a full installation of Microsoft Access.
This file is an important component of Microsoft Access security.
If you develop database applications, it is important that you have a
good understanding of the workgroup information file. It is a good
idea to reserve the last phase of the development process for applying
security in Access. Until then, you can develop the database
application in an unsecured database.
A workgroup is a group of users who share data in a multiuser
environment. When security is implemented on a database, the user and
group accounts are recorded in the workgroup information file. User
passwords are also stored in the workgroup information file.
IMPORTANT: If you establish Access security in a database, Microsoft
recommends that you store a backup copy of the workgroup information
file in a safe location. If the file is lost or damaged, the only way
to recover the workgroup information file quickly is to restore the
file from a backup copy. If you do not have a backup copy, you must
re-create the User and Group Accounts with the same Personal IDs that
were originally assigned. If the new workgroup information file is not
created exactly as the original file, you will not be able to open the
database with the workgroup file.
Access uses the workgroup information file even when the database has
not been secured. The default Admin user account, which is stored in
the workgroup information file, is used to open all unsecured
databases. If you assign a password to the Admin user, you will
receive a logon prompt when you reopen the database.
The Access database that SQL Server is trying to access is being used by another user. Go to the folder where the database is stored. With Access 2003, the database file itself will end in 'mdb'. If there is a file with the same name but ending in 'idb', it signals that there is a user currently using the 'mdb' file. Have the user exit the database and then run your package. If you can't find the user using the file, make a copy of the file in another folder and edit your SSIS package to reflect the change.
I am having trouble sorting through all the information / various options in regards to Access 2007 used in a multi-user environment. Here is a brief description of my current situation. At work there is the "Business LAN" which I can log on and use to monitor two other servers via remote desktop. The business LAN is strictly controlled by our IT department and no one is permitted to install any software or drivers without their consent. I do have administrative privileges on both servers though.
The two servers that I log on to using RD are used for essentially the same task, which is to monitor and control the heat to different process lines. Each server runs a different program to accomplish this task but both programs use SQL Server as a back end.
I created two access databases (one on each server because they are currently behind seperate firewalls) in order to query information from the backend SQL side of these programs and combine it with relative information I have compiled in tables in order to add more detail to the data the programs are collecting. My program is still in the debug stage but ultimately this information can then be accessed by field techs / maintenance in order to make their job easier. Maintenance staff can also add even more information based on the status of repairs etc....Last, I have created reports which can be run by Managers / Engineers who are looking for an overall status of their area.
Both access db's are split so that the back ends are seperate from the forms, queries, etc... I use an ODBC data source to import a link to SQL. I am using vba for user authentication, user logging record updates, and user / group access control. Everything works the way I intended except the fact I everyone who logs on the server will be trying to run the same copy of the front end. For example, I had a co-worker log on to the server via RD to test the program and I logged on from my desk. After logging in I could see the forms he had open. Access was already running. Without being able to install access locally (or even runtime, due to IT restrictions) on to each individuals workstation, I'm not sure what approach to take to resolve this.
Additional info, Server 1
One of the servers is considered to be the "master server" in which a number of client stations "slave servers" all communicate with. The only way to access folders on themaster server is log on to the client station and run RD.
Server 2
This server is considered to be the "historian". It communicates with a terminal server in which users log on using RD and run applications which use SQL backend which resides on the historian. I have been able to set up shares so that certain folders are visible on the historian from the terminal server.
Can anyone tell me what my best option is?
Thanks in advance.
CTN
It's really crazy the way some IT departments do everything possible to make it hard to do your job well.
You allude to users logging on via Terminal Server. If so, perhaps you can store the front ends in the user profiles of their Terminal Server logons? This assumes they're not just using the two default admininstrative Terminal Server logons, of course.
The other thing that's not clear to me is why you need a back end at all in Access/Jet/ACE -- why not just link via ODBC to the SQL Server and use that data directly? The only reason to have an independent Jet/ACE file with data tables in it in that scenario is if there is data you're storing for your Access application that is not stored in the SQL Server. You might also have temp tables (e.g., for staging complicated reports, etc.), but those should be in a temp database on a per-user basis, not in a shared back end.
Here is a suggestion how to implement what David Fenton wrote: write a simple batch script which copies your frontend from the installation path to %TEMP% (the temporary folder of the current user session) and runs the frontend from there. Something along the lines of
rem make sure current directory is where the script is
cd /d %~d0%~p0
rem assume frontend.mdb is in the same folder as the script
copy /y frontend.mdb %temp%
start %temp%\frontend.mdb
Tell your users not to run the frontend directly, only via the batch script, then everyone should get his own copy of the frontend. Or, give your frontend a different suffix in the installation path and rename it to "frontend.mdb" when copying to %temp%.
I'm wondering what techniques you use to store the database credentials for your application. I'm specifically concerned with java webapps, but I don't think there's any need to limit the questions to that.
things to consider:
Do you use property files,xml configs, other?
Is it bundled into your application(ie in a jar file) or stored seperately on the file system somewhere?
Is the password encrypted? If so, what encryption scheme do you use?
Since you're leaving the question open to platform, I'll add that database credentials for .NET apps are stored in the web.config file. From version 2.0 and above, there is a specific ConnectionStrings section that allows for easier programmatic access to the connection string.
In addition to having IIS automatically block direct requests to the web.config file by default, you can also use an IIS command to encrypt the ConnectionString section of the web.config file. This encryption is machine specific, adding to its strengths, and the .NET runtime will also decrypt the connection string on the fly when you access it, so there is no need for additional coding in your application to work with it.
With Java, database connection pools should be passed into webapps by the container. This is in the standard declarable in WEB-INF/web.xml as resources. The same applies to mail sessions and other external resources that may vary from installation to installation. Look up JNDI for more information on this)
The nice part with this is that the application doesn't care about how to actually connect to anything outside. It will not see any passwords, because the container itself will use them.
In tomcat this is configured either from context files (e.g.) in conf/Catalina/localhost/ , conf/server.xml or - preferably only for dev environments, from the webapps META-INF/context.xml. Other environments have their own configuration location or application.
The encryption of passwords actually depends on the container. Tomcat stores them in plaintext, but the application itself won't see it. I don't know about the mechanics in other environments.
On the Microsoft stack, things can be very nice.
You create a network user account in Active Directory with almost no permissions. You configure IIS to run your webapp as that user. You grant that user read access to the web folders and files on the disk. You configure SQL Server to grant that user read/write permissions on the tables you want. And in the connection string, you instruct the db client to connect as the user account which the webapp is currently being run as.
There is only one actual user account, although it is visible in multiple places. This user account has extremely limited permissions. There is no storing passwords anywhere, even if encrypted. There is no configuration that has to be done in code for this to work (it's all in setting up the permissions).
Depends on the app server.
I usually use JNDI lookups for the data source, so credentials are stored on the app server that handles the connection pool. No need to put anything other than the JNDI name in configuration that way.
Yes, the password is encrypted on WebLogic.
On Tomcat things can be dicey. Connection info is in META-INF/context.xml, which means plain text for the password. I only do that for development, never in production.
In Django, the credentials are in your settings.py configuration file. Since this is not generally kept in your /var/www/ directory tree, it's very safe.
Also, a single Django application may be used (and reused) for many web sites or web servers on the same host, each with it's own distinct settings. So the settings.py configuration is not bundled with the app, but is part of a single deployment of the app.
For asp.net:
I store global parameters such as the connection string and repository paths in the Registry and then a reference to the registry entry in the web.config.
The main reason being that I often find I have to write a stand alone executable to run background tasks and other automated features that require access to the same parameters. Therefore keeping everything that is truly global in one easily accessible place makes for an easier life.
As stated before, no platform specified, and using some ideas from earlier answers:
I am considering a containerised application. You could store the password for the database in a file in the container. The first step of your application would be to establish the database connection, even before listening on web requests. With a successful db connection the file with the credentials is deleted and the variables containing the these, are removed. So when you start serving requests, the only thing that remains, is an open database handle to use from this moment on. If for any reason the database connection is lost, you simply quit and wait to restart the container, the credentials file will be there again.
Which of these are good places to keep your web app’s database credentials?
In a separate file in your source code
In a separate file on your web server host
In your database
None. The database credentials should never be stored
What is the most secure and easier way to send approx. 1000 different records into database that is not directly accessible - MySQL database on Web provider's server - using Windows application
.
Data will be stored into different tables.
Edited:
The application will be distributed to users who have no idea what is database or putty or... They just install my application, open it, enter some data and press Submit.
Currently I'm using php to upload the generated script into webserver and there process it. I think I should also include some signature to the file to avoid some "drop..." hacks.
If you can export the data as a sql script you can just run it against the remote server using your application of choice. 1000 records wont create that big a script.
In current project on my job we have the same situation - remote (faraway) database.
I made next solution: serialization sql query into xml and putting it via HTTP to web daemon, which is running on remote server instead of open sql server. Daemon checks credentials and executes query.
As I can't execute any external programs on external server, I created following solution:
My program creates script file and calculates it's salted hash
Program sends this file together with user credentials and hash into PHP page on the server
PHP page checks the username and password, then checks hash and then executes script. Only Insert and Update commands are allowed.
Is this approach secure enough?