i usually have my database updated in my development machine.
I need to transfer it to the client using some media like cd, dvd, pendrive or other.
When the client copies it and attaches it in his computer it shows readonly format and no transaction is allowed.
I don't know what i am missing to make it work?
Steps i follow:
1.) Copy database files from my computer to thumb drive
2.) hand Over it to client
3.) Client copies it to his machine
4.) removes previous one and Attaches the DB
I need to transfer it to the client
using some media like cd, dvd,
pendrive or other.
When the client copies it and attaches
it in his computer it shows readonly
format and no transaction is allowed.
Check whether the FILES are read only to start with. Not sure - but if the MEDIA is read only, I think file copies are read only, too.
It isn't totally clear what you did, but what happens if you just remove the READONLY setting? Even if it fails, you may get a useful error message that helps to point you in the right direction:
ALTER DATABASE MyDB SET MULTI_USER
And you should probably review "Copying Databases to Other Servers" and sp_detach_db in Books Online to make sure that whatever exactly you're doing is actually supported. For what it's worth, BACKUP and RESTORE is often the easiest way to go in my experience.
Just give write permissions to the SQLite file in the assets folder (if you are using a database of yours).
Related
I have a shared accde file on a network drive. Occasionally we will have an inconsistent state problem. The error message appears below. It seems to be associated with network connection interruptions for even one user. We have an example when a user unplugged the Ethernet and switched automatically to wireless and other examples where users have left the database open overnight, perhaps when a machine hibernates.
Once this happens the one user cannot work and no one can open the accde file. Other users who have the database open can continue to work.
After the problem occurs it remains until everyone closes the database. At that time it completes whatever recovery it requires and all users can get back in.
This was disruptive when we had six users in one room. Now we have 17 in two cities and a few work-from-home users. It's becoming intolerable.
The obvious answer is to move away from Access. We're working on it but it's a long way off. In the mean time I would appreciate any advice.
Is there a way to prevent the problem entirely?
Is there a VBA way to detect the problem in the instances that are not showing the error message?
Is there something I'm not thinking of?
What would you do?
Error message:
Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database. During this process, a backup copy of the database will be made and all recovered objects will be placed in a new database. Access with then open the new database. The names of objects that were not successfully recovered will be logged in the "Recovery Error" table.
The solution that Microsoft gives is Splitting the database, which just means to put the data elements on a shared server, and everyone has their own copy of the front end.
This might cause problems if that front end needs to be updated (e.g. additional forms). Details here:
http://answers.microsoft.com/en-us/office/forum/office_2007-access/microsoft-office-has-detected-that-this-database/3fb41c70-f7ba-41dd-a847-e62203071466?auth=1
Check the row count in the tables, the tables most likely have large amounts of data creating latency on the read and write queries, causing the locking.
Archive older data and keep the database small and neat, perhaps create referenced databases for archived information
I gather that your MS Access database is getting corrupt when up put it on a shared drive. A Microsoft Access database may get corrupt when in a multi- user environment. Here are the workaround that you can use in order to fix it.
Step 1: Run Command Prompt as Administrator
Click on the Windows icon and type Command Prompt. Then right-click on the Command Prompt and choose Run as administrator option.
Step 2: Execute Compact and Repair Database Command
In the command prompt window, type the following command and then press ‘Enter’.
msaccess <database file name> /compact
In the command, replace <database filename> with database path. For instance,
msaccess "C:\Program Files\Reports.mdb" /compact
This will start the process to compact and repair the faulty Access database file.
Otherwise, You can check out this thread for an alternative solution : https://dba.stackexchange.com/questions/71906/ms-access-mdb-ldb-database-corrupted/171275#171275
I am receiving this error message while creating DB from a .mdf and .ldf files located on a network drive.
Query executed:
create database DatabaseName ON
(FileName = '\\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf'),
(FileName = '\\gyancluster-sql\g$\Backup\WSS_Content_DB_log.ldf')
for attach
GO
Error
The file "\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf" is on a
network path that is not supported for database files.
So what is your problem? What is the question? No question there - just dumping a sentence ;)
I mean, without wanting to sound too sarcastic, but you CAN read, or?
The file "\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf" is on a network path that is not supported for database
files.
That is pretty clear, isn't it? It is not supported - for VERY good reasons, btw., until now.
Are you asking us now whether MS lies? No, they do not lie - this is not supported. They REALLY MEAN what they say.
There are ways around (http://support.microsoft.com/kb/304261) but that is it ;)
Do you want us to reword the error message? Maybe into "dude, that wont worx, not cool, see"? Clearer?
Seriously - soudns harsh, but I always wonder why people do not actually READ the error message.
Use DBCC TRACEON(1807) before trying to create the Database.
Also, you can add the linea "-t 1807" to the MSSQL server startup parameters, it will make the change permanent. The command above let you use network storage, but on a reboot you will lose the flag.
You are lucky that the OS is warning you that opening database files directly over a network is a bad idea. Older database api's let you do that with no warning and then network users of that database application are forever blighted with corrupt databases.
If \gyancluster-sql\g$ refers for Local Disk G on the computer gyancluster-sql which also happens to be where the sql service is running, then you really should be using
create database DatabaseName ON
(FileName = 'G:\Backup\WSS_Content_DB.mdf'),
(FileName = 'G:\Backup\WSS_Content_DB_log.ldf')
for attach
GO
Note this remains true even if you are running the script from another computer.
It would still be a bad idea, but you may able to use the UNC names, but only if the service under which sql is running is able to access the share(eg if running under the Domain Administrator account), but that is normally considered an unnecessary security risk.
If you are really trying to store the database on network device, then obviously that means the sql service does need access to the share, so that would be the first thing to check, but you also need to read the Microsoft article which Chris Dickson has pointed you to (ie http://support.microsoft.com/kb/304261) which details when this is supported.
You need to enable the database file over network shared, the following post explain step by step how to do it.
https://blogs.msdn.microsoft.com/varund/2010/09/02/create-a-sql-server-database-on-a-network-shared-drive/
The same post explains the risks to do it.
I hope this helps
Regards
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 have the following problem and I need to know if there´s a way to fix it.
I have a client who was cheap enough to decline buying a backup plan for his postgreSQL databases on the main system that runs his company and as I thought it would happen some day, some OS files crashed during a blackout and the OS needs to be reinstalled.
This client didn't have any backups of the databases but I managed to save the PostgreSQL main directory. I read that the databases are stored somehow inside the data directory of the postgres main folder.
My question is: Is there any way to recover the databases from the data folder only? I am working in a windows environment (XP service pack 2) with PostgreSQL 8.2 and I need to reinstall PostgreSQL in a new server. I would need to recreate the databases in the new environment and somehow attach the old files to the new database instances. I know that's possible in SQL Server because of the way that engine stores the databases but I have no clue in postgres.
Any ideas? They would be much appreciated.
If you have the whole data folder, you have everything you need (as long as architecture is the same). Just try restoring it on another machine before wiping this one out, in case you didn't copy something.
Just save the data directory to disk. When launching Postgres, set the parameter telling it where the data directory is (see: wiki.postgresql.org). Or remove original data directory of the fresh installation and place the copy in its place.
This is possible, you just need to copy the "data" folder (inside the Postgres installation folder) from the old computer to the new one, but there are a few things to keep in mind.
First, before you copy the files, you must stop the Postgres server service. So, Control Panel->Administrative tools->Services, find Postgres service and stop it. When you're done copying the files and setting permissions, start it again.
Second, you need to set the permissions for the data files. Because postgres server actually runs on another user account, it will not be able to access the files if you just copy them into the data folder, because it will not have permissions to do so. So you need to change the ownership of the files to the "postgres" user. I had to use subinacl for this, install it first, and then use it from command prompt like this (first navigate to folder where you installed it):
subinacl /subdirectories "C:\Program Files\PostgreSQL\8.2\data\*" /setowner=postgres
(Changing ownership should also be possible to do from the explorer: first you must disable "Use simple file sharing" in Folder options, then a "Security" tab will appear in the folder Properties dialog, and there are options there to set permissions and change ownership, but I wasn't able to do it that way.)
Now, if the server service can't start after you start it manually again, you can usually see the reason in the Event viewer (Administrative tools->Event viewer). Postgres will throw an error event, and inspecting it will give you a clue about what the problem is (sometimes it will complain about a postmaster.pid file, just remove it, etc.).
The question is very old, but I want to share an effective method that I found.
If you have not got a backup with "pg_dump" and your old data is folder, try the following steps.
In the Postgres database, add records to the "pg_database" table. With a manager program or "insert into".
Make the necessary check and change the following insert query and run it.
The query will return an OID after it has worked. Create a folder with the name of this number. Once you have copied your old data into this folder, the use is now ready.
/*
------------------------------------------
*** Recover From Folder ***
------------------------------------------
Check this table on your own system.
Change the differences below.
*/
INSERT INTO
pg_catalog.pg_database(
datname, datdba, encoding, datcollate, datctype, datistemplate, datallowconn,
datconnlimit, datlastsysoid, datfrozenxid, datminmxid, dattablespace, datacl)
VALUES(
-- Write Your collation
'NewDBname', 10, 6, 'Turkish_Turkey.1254', 'Turkish_Turkey.1254',
False, True, -1, 12400, '536', '1', 1663, Null);
/*
Create a folder in the Data directory under the name below New OID.
All old backup files in the directory "data\base\Old OID" are the directory with the new OID number
Copy. The database is now ready for use.
*/
select oid from pg_database a where a.datname = 'NewDBname';
As shown by move database to another hard drive. All we need to do is to modify the registry table and file permissions. By modifying registry table(shown in image 1), postgresql server know the new location of data.
modify registry
If you have issues with permissions or with stuff like icacls during installation to old data folder then try my solution from sister website.
https://superuser.com/a/1611934/1254226
I do so but the most tricky part was to change the owner permission:
go to services from administative tools
find postgres service and double click on it
at log on tab change to local system
then restart
In SQL Server 2008 I can attach databases located only in its predefined folder (C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA). On may occasions, especially when I read a book, I need to attach test database from desktop rather then copy each database every time I need it, but SQL Server does not allow me to access desktop.
Any workaround to solve this issue?
It's probably a matter of granting the account running the SQL service appropriate permissions to your desktop folder (C:\Documents and Settings\YourLogin\Desktop). But, rather than use a location like Desktop that is specific to your login and possibly inaccessible to the account running the SQL service, why not use a common holding location for these files? Something like C:\AdHocDBs or whatever you want to call it.
When a database file (data or log) is first created, it is (of course) located in a specific drive and folder. When a backup is created, this information is stored as part of the backup. A database RESTORE command will assume that the database is to be restored in the exact same location, unless instructed otherwise. To do this, in the RESTORE command under the "with" option, you must include the "move" option. It looks something like this:
RESTORE ...
with
move '<logcalFileName>' to 'physicalFileName'
,move '<logcalLogFileName>' to 'physicalLogFileName'
One move must be included for each file to be so moved, so you usually end up with at least two of these clauses. The tricky part is that you must know the database files' logical names. These can be found via sp_helpFile on an attached database, and
RESTORE FILELISTONLY
from disk = '<backupFile>'
On an existing backup.
(I'm sure all this can be done somehow with the SSMS backup/restore GUIs. I switched over to TSQL-based scripts years ago, to provide quick and flexible access to all the features wrapped in the backup and restore commands.)