Error opening index file of table 1c 7.7. Converting a single index file to a tag

Introduction

It was a sunny summer day and there was no sign of trouble when the phone rang and the employee on the other end said, "Looks like I killed the client base." After interrogation with partiality, it turned out the following: on a regular remote desktop (RDP), a configuration update was carried out with a database restructuring, such updates are done one thousand five hundred times a day. However, this time something went wrong and the database crashed.

At re-launch the program gave a message

and after that it fell out into Windows. Having a backup copy would have made it possible to restore the database in no time, but the human carelessness of the employee, who did not spend an extra couple of minutes to create it, led to the fact that it took about four days to fix the problem, several incorrect steps were taken that did not lead to a significant result. Below I describe the correct way.

Restoring the base

A search on the Internet led to pages describing these problems without a solution, but soon two important links were found that were the starting point for an accurate recovery:

Step # 1.We do backup spoiled base

In addition to viewing the list of tables, there is an important function for unloading the configuration. We launch the utility, open the database. The base opened with no error messages, that's a good sign!

Step # 3. Analyzing the structure of the damaged database file

So, as you know, a CD file is essentially a storage of table files. Open the Hex editor (for example, open source http://en.wikipedia.org/wiki/HxD), follow the link 0x4000. There is a table of offsets of the main database and configuration tables.

Lyrical digression

All addresses are stored in absolute addressing, which makes it difficult to correct in manual mode, if some table is damaged, not the first in the list. On the other hand, it simplifies the work of 1C programmers and speeds up the process of loading the necessary tables into memory.

So let's take a look at the table from the HEX editor:

This picture on the left side shows the HEX editor on the right side of the list of tables from the Tool_1CD utility. They are in the same order as they appear in the CD file. Here we see that the CONFIG table starts at 0x5000 and ends at 0x31F0FFF, where the table starts next. CONFIGSAVE at 0x31F1000 (for those who have never programmed in assembler, I will say that numbers in machine codes are written from right to left - a relic of the tsarist regime). Strictly speaking, 0x5000 is the table header CONFIG, which refers to one more header, and then the table itself follows (see the description of the file format in the link above). It is reasonable to assume that if 1C swears at the configuration, therefore, we need to fix this particular table, for this we need to pull out the CONFIG table from the saved configuration (or if it is not saved, take the configuration as close as possible to the damaged one) and substitute it at the address 0x5000, but the table should not go beyond 0x31F0FFF.

Upd 10/10/2012

Important note :

1C refers to tables by name, and it does not matter which table is in the list first, which is the second, etc.It's just that when creating a new database, 1C creates the necessary tables one after another in the order in which this creation was written by 1C programmers. Therefore, it always turns out that CONFIG comes first, CONFIGSAVE comes second, etc. But if the first table were some _REFERENCE152, and CONFIG would be the seventeenth in the list, 1C would work quietly with such a base.

Step number 4a. Load the unloaded configuration into the empty configuration (sorry for the pun)

Loaded. They wrote it down. We look in the HEX editor

So, something is wrong, some new table has been added. Hence the conclusion: Recovery should be done on the same platform release as the damaged database.

Step 5b. We load the unloaded configuration of the same platform version into the empty configuration

Let's see the result:

Yes, the result is also not very good. The CONFIG table ends at 0x10FFF and does not appear to be restructured. Okay, let's try to copy the Tool_1CD worksheet to a non-working database. Select the block in the working base and copy it with replacement at 0x5000 to the damaged base:

Open Tool_1CD, open the corrupted base, but alas Tool_1CD hangs when trying to view the CONFIG table. After several incorrect steps, I got an idea: what if 1C structures tables when loading a database? Then it remains to unload and load the database with the working configuration.

Step number 5c. We load the unloaded configuration of the same platform version into the empty configuration, unload and load the database (not the configuration!).

Let's see how the offsets look now:

Better now. CONFIGSAVE is now located at 0x31FC000, which is greater than 0x31F1000. How do you copy a larger CONFIG table block in a production database to a smaller one in a corrupted database? The answer is simple: you need to remove the metadata in the working configuration that does not affect its structure: common modules, pictures, reports, processing, etc. It is important for us to start the damaged database, we will restore the configuration later.

After several iterations of deleting, unloading and loading the database, I got the following picture:

Finally: CONFIGSAVE starts at 0x313B0000<0x31F1000. Now select the block 0x5000- x313AFFF in the working base and in the address 0x5000 in the damaged base, copy it with replacement

We write it down. We open 1C. Ok, everything worked.

Upd 10/10/2012

Important note

As a rule, at offset 0x4000, links to table description files are contained. And already in the files of the description of the tables, there are references to the tables of records, indexes and BLOBs. In general, if the CONFIG table "starts" at 0x5000 and the CONFIGSAVE table at 0x31f1000, there is no guarantee that there is no block between 0x5000 and 0x31f1000 that belongs to any table other than CONFIG. In most cases, the CONFIG table is not fragmented, this is explained, I think, by the fact that such an arrangement of files of one table one after another, so that the whole table is, as it were, in a 1CD file in one continuous piece, is formed as a result of applying database compression during testing and fixing or using the chdbfl.exe utility.

It remains only to load the working configuration into the database in order to restore the working database. That's it, the base has been restored.

P.S. Of course, this case describes the correction of simple breakdowns, however, even such a simple case can baffle experienced professionals when there are no standard ways to solve the problem. Don't forget to make backups.

There are times when a table or index can get corrupted. This could be due to changes in mysql or in the dataset being processed. For example, there is an error in the collation, the table needs to be rebuilt to update the indexes for character columns that use collation. It may also be necessary to restore tables after checking the integrity of the tables with the CHECK TABLE, mysqlcheck or mysql_upgrade commands.

To restore, re-create tables in the event of a mysql database update or downgrade, use only the dump-and-reload method (creating a backup of a table and then restoring from it). Therefore, before updating the mysql database or downgrading the database, you must create a database dump, for example using mysqldump. After upgrading or downgrading, restore the database from the dump file. If you use this method only for rebuilding indexes, then dump and restore can be done both before and after the update or rollback of the version.

To recreate the table using dump and restore, follow these steps:

mysqldump db_name table1> dump_table.sql

mysql db_name< dump_teble.sql

To restore all tables, there is no need to list them, use the following commands:

mysqldump db_name> dump.sql

mysql db_name< dump.sql

To restore all tables in all databases mysql data use option —All-databases

mysqldump --all-databases> dump.sql

mysql< dump.sql

To recreate the table using the command ALTER TABLE do not change the storage engine, use the one that is already there, for example l for MyIsam:

ALTER TABLE table1 ENGINE = MyISAM

If you are not sure which storage engine is used for the table, you can find out by running the command:

SHOW CREATE TABLE to display table parameters.

If you need to re-create the table because checking the table gave a message that the table was corrupted, use the command: REPAIR TABLE, if only given type storage table supports this operation. For example MyISAM supports, so we run:

REPAIR TABLE table1

For table storage systems InnoDB, REPAIR TABLE not supported... To recreate and restore such tables use mysqldump to create a dump and then restore it, as described at the beginning.

mysqlcheck —repair- provides the ability to restore tables in the same way as REPAIR TABLE, only this expression is more convenient since you can use the options —Databases or —all-databases to repair all tables at once in specific databases and in all mysql databases, respectively:

mysqlcheck --repair --databases db_name1 db_name2 ...

mysqlcheck —repair —all-databases

MySQL 5.1.24 has bug # 27877 utf8_general_ci and ucs2_general_ci encodings (codings), it was fixed in MySQL 5.1.62, 5.5.21 and 5.6.5. Install any of the patched versions, then convert tables using one of the following methods:

Change encoding (collation) to utf8_general_mysql500_ci and ucs2_general_mysql500_ci, which corresponds to utf8_general_ci and ucs2_general_ci in MySQL 5.1.24

To convert the affected tables after the upgrade, change the settings using the new collation values. Suppose the table contains one or more problematic utf8 columns. To convert such tables, use the command:

ALTER TABLE table1 CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

To apply changes to columns, use the same command without COLLATE:

ALTER TABLE table1 MODIFY c1 CHAR (N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

To update using a dump and restore procedure. Create a dump file, change the encoding for expressions in it CREATE TABLE, it can be done by auto replacement, then restore from the dump file.

After the corrections made CHECK TABLE should not give errors.

If you have problems with the mysql Database and you cannot solve them, please contact us (contacts), we will be happy to help you.

The index file can only be opened if the corresponding table file has been opened previously. Otherwise, an error message will be displayed. To open the index file, you need to issue the command:

SET INDEX TO [list of index files]

[OP< cdx-file>]]

The function of the options is the same as in the USE and INDEX ON commands.

You can open an existing index file at the same time as opening a table file using the USE command (see section 2.2 “Opening a Table”).

To close all index files, one of the commands must be given: either SET INDEX TO without options, or CLOSE INDEX.

Replacing the current index

Several index files can be open for each table at the same time, but only one index will be current (active). By default, it is assumed that the current index will be the first in order in the index file, the name of which is indicated first in the list of names of index files of the USE command or command SET INDEX TO.

Any index from the current index file can be made current using the command

SET ORDER TO

[<выр. N1> | < idx-file> | ]

[ ASCENDING | DESCENDING]

Options assignment:

<выр.Nl> - sets the current index by its ordinal number in the multi-index file.

- makes a single-index file current.

TAG<имя тега> - sets the current index by tag name from the specified multi-index file. If the option is omitted, the tag is selected from the current multi-index file.

IN<выр.N2> - indicates the number of the work area in which the index file is located. The option is used if the table file is open in one work area, and the index file is in another work area.

You can also make the index current using the Table Designer dialog box by moving the description string of the desired index to the first place.

Rebuilding index files

Changes to large tables are time-consuming because each change rebuilds all open index files. To save time, the index files are closed and the table modified. However, in this scenario, there is a mismatch between the updated table and the index files. To eliminate this discrepancy, the index files must be rebuilt. After opening all index files belonging to the modified tabular file, you need to give a command REINDEX. The command affects all index files open in the current work area. Re-indexing can also be performed by issuing the command from the Main Menu Table -> Rebuild Indexes.

Converting a single index file to a tag

If a table file owns one or more single-index files, then they can be copied as tags into a multi-index file. For these purposes, use the command

COPY INDEXES< namesidx -files> | ALL

The ALL option is specified if you want to copy all single-index files. In this case, the list of names <имена idx-файлов> not specified. Tags are assigned the names of single-index files. When copying several single-index files, their names are listed separated by commas. If the TO option is omitted, then single-index files are copied to the current multi-index file. If the TO option contains the name of a non-existent multi-index file, it is created.

The reverse operation is also possible, that is, one tag is converted (copied) into a single-index file using the command:

COPY TAG<список имен тегов>(OF<с dx-file>] TO< idx-file>]

The multi-index file must be opened beforehand. You can copy individual tags by specifying<список имен тегов>, or all tags using the ALL option.

Sooner or later, a difficult moment comes in the life of any 1C user when a favorite program refuses to deal with him, not starting at all or giving out often unintelligible messages for a person. So, what is 1C trying to tell us and what can we do for it?

1. "Error loading metadata"

2. "The sort order set for the database is different from the system!"

This error occurs when the system encoding and encoding of the infobase are different (see http://www.goto1c.ru/2011/04/ordnochkprm.html).

3. "Data Lock Error"

Your database is used in exclusive mode (perhaps it is you yourself). To eliminate this problem, you need to close the 1C: Enterprise session with exclusive access to the database and enter in split mode. If 1C: Enterprise in exclusive mode is not running on your computer, then two options are possible.

The first option is applicable if there are few computers in the network using 1C: Enterprise or they are located close to each other. Selecting the 1C: Enterprise Help -> About the program menu item on each computer, you will see in the line Working hours... If "Exclusive" is written on the left, then you need to close 1C: Enterprise on this computer.

The second option should be used when there are many computers on the network. Then you need to start the Monitor using the Start -> Programs-> 1C: Enterprise-> User Monitor command. After starting the monitor, you need to select the Monitor -> Active users menu item. You will see a list of computers from which to this moment the base is used (each line is a running 1C component: Configurator, Enterprise, Monitor, Debugger). If you pay attention to the leftmost column, you will see that 1C: Enterprise is running on one of the computers in exclusive mode (this is displayed in red exclamation mark next to the icon). Go to this computer and close 1C: Enterprise there. The problem should now be resolved.

Sometimes it is possible that some computer has shut down incorrectly (or simply "frozen"), then you need to turn it off and turn it on again. If it is impossible to determine which computer has occupied the base, and the Monitor does not indicate a computer using exclusive mode, then you will have to find and terminate the 1cv7.exe process in the Manager Windows tasks or turn off all computers (you can do it one at a time, trying to start 1C after turning off each computer).

4. "User directory is busy"

5. "Database directory not found"

This happened due to the fact that the folder in which the 1C database is located is inaccessible. If the database is on your computer, then most likely you have moved it somewhere. Remember if you moved any directories (folders) to recent times... If you know exactly where the base was moved, then when starting 1C in the dialog box, select the "Change" button (on the right there are the OK, Cancel and the next buttons - "Change"). Specify a new path to the database and, by clicking on the OK button, start 1C: Enterprise again.

If the base is not on your computer, but on remote server, it is better to seek help from the person who is responsible for the performance of computers in your company. If you nevertheless decide to fix the problem on your own, then, firstly, you need to check the presence of a network between the two computers (you can simply check the presence of the server computer in the list of computers available for the client by clicking on the icon "My Network Places"). Secondly, you need to find out the location of the directory with the base on the server. After that, by clicking on the "Change" button in the 1C: Enterprise launch dialog box, select "My Network Places" -> Server where the database is located -> Specify the path to the database.

6. "Error opening table index file. To restore index files, run the program in exclusive mode "

To solve this problem, you need to run the program in exclusive mode (check the "Exclusively" box when starting the program). Of course, you will first have to ask all users to exit 1C: Enterprise. You should answer affirmatively to the offer to restore index files. This process can take a significant amount of time, from 1-2 minutes for bases of 5-10 megabytes to about an hour for large bases. If you cannot start the system in exclusive mode, although you are sure that all users have exited the program, then first check your computer, perhaps there is a running copy of the program left there. If this does not help, then try turning off the client machines (you can do one at a time, with a check after each). It is likely that one of the programs was terminated incorrectly and did not free the base.

7. "The log file is damaged"

In the directory of your database (the path to the database is written at the bottom in the launch window) there is a Syslog subdirectory. This directory contains the file 1cv 7.mlg, this is the log file. Move it to a different directory; if you think you don't need the log file, you can delete it. The main thing is to remove the log file from this directory. The next time you start 1C: Enterprise, it should boot successfully and create an empty log file.

8. When you start the program, a pop-up screen appears with the inscription 1C: Enterprise and immediately disappears.

This error occurs when the platform detects files to run, but the current account (operating system account, not to be confused with account"1C: Enterprise") no access rights to the directory where the infobase is located. To start 1C: Enterprise, you need to write to this directory. To fix the situation from the server where the base is located, select common resource(disk or directory with the base), right-click, select the Properties menu, the Access tab, set the Full value (or rearrange the indicator in "Open general access to the folder "for Windows 2000). Save the changes, try starting 1C: Enterprise again.

9. Runtime Error! Program c: \ Program Files \ 1Cv77 \ Bin \ 1Cv77.exe. Abnormal termination "

There are several possible reasons for this error. First, copy the directory of your base to a different location so that even in the worst case (during the repair process the lights were turned off) you can return to the situation before the start of the repair. You can do it yourself next steps fixes this error. After each step, try to launch 1C: Enterprise.

a) Restart your computer.

b) Reinstall 1C: Enterprise.

c) Copy the file 1Cv 7.md, which is located in the NEW _STRU directory of your base, to the directory with the base. For example, if your base is in the c: \ 1C \ base directory, then you need to copy the 1Cv 7.md file from c: \ 1C \ base \ NEW _STRU to c: \ 1C \ base. To the question: "Do you want to replace the current file?" the answer should be “Yes”.

d) Launch the Configurator, select Administration -> IB Testing and Correction. Click on the Run button.

10. “Fatal database error. Code - 10. Error opening database dictionary "

Copy the file 1Cv7.dd, which is located in the NEW_STRU directory of your base, to the directory of your base. For example, if your base is in the c: \ 1C \ base directory, then you need to copy the 1Cv7.dd file from c: \ 1C \ base \ NEW_STRU to c: \ 1C \ base. To the question: "Do you want to replace the current file?" the answer should be “Yes”. If such a file does not exist in the NEW_STRU directory, but you know the configuration password, you can fix the problems by renaming any metadata object to itself (for example, erase the last letter "l" in the identifier of the Constant "MainFile" and put it back in). Save the configuration.

11. DT table access error *

Exceeded the maximum allowable amount at the same time open files on Windows 9x.

The fact is that Windows 95/98 can open no more than 1024 files at a time. This limitation takes effect if in the network mode of operation, the database is located on a shared disk of a computer running under Windows control 95/98. When starting 1C, each connected user opens all .dbf and .cdx files included in the configuration. Depending on the complexity of the configuration, 3-6 users can simultaneously work with 1C in this mode.

If you encounter such a problem, you should use a WinNT / 2000/2003 computer as a file server (i.e. a computer on which the infobase directory is stored). You just need to keep in mind that WinNT Workstation (2000 Professional) does not have a limit on the number of open files, but allows no more than 10 simultaneous connections... Those. no more than 10 users can work with databases on such a computer at the same time. If you want to work more users at the same time, that is, it makes sense to consider the option with a dedicated server and operating systems Windows 2000/2003 Server.

If you transferred the base to Windows 2003 Server, and you keep getting the same error, then check the number of licenses for connecting users (computers) in Win Server 2003 - there are only 5 by default.

12. "Program protection key not found"

This error can occur for a number of reasons. The solution options depend on whether you have a network version or a local version. Let's start with local as from a simpler case.

We suggest you follow these steps. After each attempt, please try to launch 1C: Enterprise. It is possible that the problem will be solved at the very first step, and then all subsequent ones will not be needed.

a) Restart your computer by clicking Start -> Shut Down -> Restart Computer -> OK. Wait for the computer to restart, then try to start 1C again.

b) You may have forgotten to install the protection driver when installing the program. Then you need to launch it by clicking Start -> Programs-> 1C: Enterprise 7.7-> Installing the protection driver. Restart your computer and try to launch 1C: Enterprise again. If, for some reason, the driver was not installed, then install it from the disc supplied with the software or download it from the site http://www.aladdin.com/support/hasp/hasp4/enduser.aspx.

c) Check the physical presence of the key on the computer, it may have jumped out of the computer. To do this, you need to get to the back of the computer case, where the wires are connected. Important: It is highly recommended that you turn off your computer first. The key looks like a block of about 3x4x1 cm. Most likely, it will be red or white. The key is inserted into the LPT port (in the same place as the printer). In any case, you can only insert the key into the LPT port. Important: you do not need to apply great force, the effort should be comparable to the effort when lifting a glass of tea. If the key does not fit into the port, do not try to insert it by force, as either it is not a key, or you are not inserting it into the LPT port. It is better to call the person in charge of computers in your company. After you have inserted the key into the port, turn on the computer and try to start 1C: Enterprise again.

d) Sometimes a printer and other equipment placed "on top" of the key can interfere with its determination by the security server. Having previously turned off the computer and the printer, try to disconnect the peripherals (most often the printer) from the computer, leaving the key in place. Now turn on your computer and try to start 1C. Of course, in this case, you will not be able to use the disconnected device.

If you are using network version, and the key is not located on your computer, it is recommended to seek help from the person who is responsible for the operation of computers in your company. If you are this person, then we can advise you to follow these steps:

a) Check that the problem computer "sees" the server on which the key is located. You can either ping the server from the command line by running the ping program from the problem computer with the server computer name as a parameter. For example, c: ping server 1c. Or you can simply check the presence of the server computer in the list of computers available to the client by clicking on the My Network Places icon. If it turns out that the problem computer does not "see" the server, then you will need to conduct standard check at network problems... We recommend starting with checking the integrity of the cables (no breaks), the operability of the hub, the operability of the network card, in addition, you should make sure that you have the necessary protocols and that they are configured correctly.

b) Make sure that the "Protection Server" application is running on the computer with the key. This program is necessary for 1C: Enterprise clients to work in a network version. You can start it by clicking Start -> Programs-> 1C: Enterprise 7.7-> Protection Server.

c) Each computer with 1C: Enterprise has a nethasp .ini file, which by default is located in C: \ Program Files \ 1Cv 77 \ BIN. This file contains settings for the program that checks for the presence of a key on the network. The file is well documented and you can probably figure out its structure. We recommend that you pay special attention to the lines of the protocols used (perhaps there is only one IPX / SPX left, which is not used at all in your network), the waiting time for the key search (with a weak network, the program may simply not have time to find it) and links to the server computer (it is possible that such a computer no longer exists, it has been moved or renamed).

Perhaps the hardware dongle is "life-long." In this situation, you need to contact your supplier. software and write an application for the exchange of the protection key. Or your copy of "1C: Enterprise" does not have given key... After all, the key is supplied only with licensed software.

The article used materials from the sites http://help1c.com, http://www.ititi.ru, http://it-specialist.perm.ru.

The most common errors 1C 7.7

1. error opening the index file of the table 1SCONST. To restore index files, run the program in exclusive mode.

Usually, this happens when initial installation bases. Solution prompted)) Run 1C in exclusive mode. 1C will index the database and it will be possible to download it.

2. the sort order is different from the system.

This error most often occurs during the initial installation of 1C on operating systems. Windows Vista and Windows 7. It is associated with various sorting mechanisms in the Windows operating system and the 1C Enterprise 7.7 program.

There are two options here.

2.1. You have a single computer with Windows Vista / 7 and 1C [b] or networked, but all computers have Windows Vista / 7.
In this case, you need to change the sorting order for 1C Enterprise 7.7 in the database itself.

It is done like this:
- We start 1C in the mode Enterprise configurator 7.7;
- Select the item " Administration" -> "Code table of IB pages";
- In the list, select the lowest item - " Current system installation ";
- OK.

2.2 You have a multi-user version, but users with different operating systems work in it - Windows XP, Windows Vista, Windows 7.
In this case, you need to disable checking the sort order.

Create a marker file with the name OrdNoChk.prm with any content. can be empty;
- if you have one database, then you can drop this file to the program itself, i.e. in \\ 1Cv77 \ Bin \ This is how we disable checking the sort order in the 1C program. But it will concern all bases anyway.
- if you have a lot of databases, then it is better to throw this file into the folder with the database. Then disabling the check of the sort order will affect only this base, where this marker (or signal) file is located. Let's say you have three bases. They work with two bases in Windows XP, and with the third - with different systems... Then, if we send the marker file only to the third base, then the third base will be able to work from different systems.

Why not throw the file OrdNoChk.prm v BIN and not disable checking the sort order for all databases at once?
Because:
- this way works only from the 26th platform and above;
- 1C warns: " The use of this feature can be recommended only in extreme cases when it is not possible to reconcile the system sorting order with the sorting order set for the infobase. If the check of the sort order is disabled in the conditions of using the distributed infobase management component, you SHOULD NOT use symbols of any alphabets, except Latin, in a three-letter identifier information bases included in the distributed. It should be borne in mind that 1C: Enterprise uses the ability to sort both mechanisms during its work, and disabling the verification of the identity of the order in them can lead to an unexpected order of the lines for the user, for example, when generating reports".

Therefore, if they work with some base in the same system, it is better to use the standard capabilities. - For example, change the page code table in the base itself and work normally.
- Or use a marker file, but selectively to the database that is used in different operating systems, without touching the rest.

This approach seems to be more flexible and correct.

In addition, the following should be remembered!

It is advisable to locate the databases on a machine with Windows XP, and OrdNoChk.prm put in folder BIN on a Windows 7 (Vista) machine. This will avoid potential problems with the operation of components such as URIB... It should be remembered that a machine with Windows 7 (Vista) can only be used to work in 1C Enterprise mode.
Any changes in the Configurator mode should be made only on a machine with Windows XP.
When the databases are located on a machine with Windows 7 (Vista), be sure to bring the IB code page to the system one (according to the first method), and use OrdNoChk.prm already on machines with Windows XP, otherwise work with URIB or simply loading previously uploaded data into IB will not be possible.

3. Error creating from component V7Plus.dll (Missing CLSID)

This error occurs due to the fact that libraries are not registered in the operating system. In this case - V7Plus.dll.
1C registers libraries dynamically, i.e. on the first call to the desired library.
But it cannot.
This usually happens due to a lack of rights, or when UAC(in Windows Vista / 7). When enabled UAC 1C works with user rights and therefore cannot register the library.
There are two solutions:
- copy V7Plus.dll(or the desired library) to the folder BIN 1C (so as not to bind to a specific database) and once confuse 1C on behalf of the Administrator, or from an account with administrator rights. Since it is launched with administrator rights, the library will be registered.
- register manually. To do this, run command line with administrator rights and give the command regsvr32 \ BIN \ V7Plus.dll, the result of execution should be a message about successful registration of the library.

4. Error "An ODBC driver for MS SQL is required to access the database Server versions 3.50.0303 or older.

The error occurs when you try to run SQL version 1C Enterprise 7.7 on Windows 7 (Vista) and consists in the lack of support for these OS versions of SQL server below SQL Server 2005 SP2.

Excerpt from Microsoft Official Press Release:
To ensure more high level security, Microsoft operating systems Windows Server 2008 and Microsoft Windows Vista will support SQL Server 2005 Express SP1 edition, and all other SQL Server editions will require SQL Server 2005 SP2 or later. More early versions SQL Server, including SQL Server 2000 (all editions including the Desktop Engine edition, also known as MSDE), SQL Server 7.0, and SQL Server 6.5, operational Windows systems Server 2008 and Windows Vista will not be supported.

There is currently no solution (and it is unlikely that it will appear).

As alternative option you can recommend starting 1C Enterprise on Windows Server 2003 in terminal mode, we recommend the same option for 1C file mode in a network with different versions of Windows.