Архивы по Категориям:

1C выгрузка + обработка php = xynta какая-то

При выгрузке из 1С-ки (в xml, для последующей вгрузки в php скриптик) индус-програмизд набыдлокодил цены в формате «12 636″. Т.е. пробел в цифру засунул.
Молодец.
Вгружаю — xynta какая-то вгружается. Не удаляется пробел этот.
Полез в код. Попробовал разные методы и str_replace (» «, «») и preg_replace на \s и \t натравливал и т.д. и т.п. хрен-то-там!
Не удаляются пробелы и всё!

Лечится только одним способом:

	function tonumericstr($str) {
	    $str = trim($str);
		    for($i=0;$i<=strlen($str);$i++) { if(is_numeric($str[$i]) || $str[$i]==".") { $new_str.=$str[$i]; } } 
	    return $new_str;
        }

ну или так для удобства можно сделать:

        //$dec_delim - отделяет целую часть от дробной
	function tonumericstr($str,$dec_delim='.') {
	    $str = trim($str);
		    for($i=0;$i<=strlen($str);$i++) { if(is_numeric($str[$i]) || $str[$i]==$dec_delim) { $new_str.=$str[$i]; } } 
	    return $new_str;
        }

доступ к базе данных на сервере возможен только из одного каталога

«Такая ошибка возникает при попытке загрузить версию 1С для SQL после того, как один из пользователей некорректно вышел из системы. В редких случаях эта ошибка может быть результатом некорректной установки конфигурации.»


Простой случай:

а)Принудительно остановить SQL-процесс можно с помощью SQL Enterprise Manager. В нем все активные процессы перечисленны в ветке “Management\Current Activity\Process Info”. Надо найти в списке справа процесс, который мешает жить, выделить его и в меню “Action” выбрать пункт “Kill Process”

б)Если пользователи работают по протоколу Named pipes, то можно просто закрыть файлы на SQL-сервере, открытые повисшим пользователем. Такие файлы имеют вид \PIPE\MSSQL$NAMEDSERVER\SQL\query. (смотреть в открытых файлах, управления компьютером)

в) Можно поступить жестче и выполнить скрипт:

USE [master]
ALTER DATABASE [наша база] SET OFFLINE WITH ROLLBACK IMMEDIATE

после выполнения скрипта рестарт службы SQL и выполнить скрипт:

USE [master]
ALTER DATABASE [наша база] SET ONLINE

Тяжелый случай:
косяк с самой базой. это печально.
Делаем бекап базы!!! (mdf и ldf файлики)

открываем query analizer
для начала переводим базу в сингл моде:

sp_dboption ‘ВАША БАЗА‘,’single user’, true

Чекаем базу:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

Если на этом все заканчивается, то поздравляю — вам повезло! Переводите в мультиюзер и вперед.

Если нет и говорит чтото подобное:
Server: Msg 602, Level 21, State 16, Line 1
Could not find row in sysindexes for database ID 7, object ID СТРАШНАЯЦЫФРА, index ID -1. Run DBCC CHECKTABLE on sysindexes.

Это очень печально
Узнаем что за таблица женской писей накрылась:

select object_name(СТРАШНАЯЦЫФРА)

Если это _1SCONNECT — поздравляю — это лечится.

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[_1SCONNECT]’) and OBJECTPROPERTY(id, N’IsUserTable’) = 1)
drop table [dbo].[_1SCONNECT]
GO

CREATE TABLE [dbo].[_1SCONNECT] (
[CONNECTUUID] [char] (36) NOT NULL
) ON [PRIMARY]
GO

затем:

EXEC sp_configure ‘allow updates’, ‘1’
RECONFIGURE WITH OVERRIDE
GO
delete from sysobjects where name=’dummy’
GO
EXEC sp_configure ‘allow updates’, ‘0’
RECONFIGURE WITH OVERRIDE
GO

потом снова:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

может выдать ошибки, но уже в других таблицах, если так — то все идет по плану.

Еще раз чекаем:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

Ошибок нет? Переводим в мульти-режим:

sp_dboption ‘ВАША БАЗА‘,’single user’, false

Наслаждаемся.
Сработало это по той причине что без данных из _1SCONNECT вполне можно жить и мы ее тупо грохнули и пересоздали. Если же такой косяк вызывает таблица с ценной информацией…