Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 75   вперед  Ctrl
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
МСУ
Бывает полное, бывает дифференциальное, бывает добавочное, бывает пофайловое.

и это всё в фокспро
27 янв 09, 16:25    [6743590]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

МСУ
Да и о каком резервном копировании Вы говорите?

О том, которое упоминает евгешка. При работе двух-трёх человек потеря
данных за сутки болезненна, но не смертельна. Но он-то втирает про
системы масштаба предприятия...

Кстати, как там в FoxPro с репликацией? Она встроенная или
обеспечивается сторонними утилитами?

Posted via ActualForum NNTP Server 1.4

27 янв 09, 16:27    [6743611]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Eugenkru1
Молодец Fox5631! Наконец то умный человек появился. Сразу видно что Fox5631 реально работал с серьёзными проектами.
Foxpro действительно подходит для огромного круга задач!
Во первых у Foxpro есть ....
Во вторых у Foxpro есть ....
В третих Foxpro удобен ....

А если я позвоню прямо сейчас - мне дадут совершенно бесплатно вот эту удобную сумку для переноски фокспро и я смогу брать его с собой на дачу, в отпуск.... И брошюрку с уникальными рецептами - дадут?
27 янв 09, 17:18    [6744046]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Dimitry Sibiryakov

МСУ
Да и о каком резервном копировании Вы говорите?

О том, которое упоминает евгешка. При работе двух-трёх человек потеря
данных за сутки болезненна, но не смертельна.

Ну Вы же сами понимаете, 2-3 человека могут неделю юзать справочную номенклатуру, пить чай и не заводить никакой информации. А могут и усердно колотить данные, + могут импортиться данные через промежуточный интеграционный слой, в помощь этим трем калекам :)
Так что тут тоже палка о двух концах.

Dimitry Sibiryakov
Но он-то втирает про
системы масштаба предприятия...

Да тоже самое. Несколько серверов. Один из них НСИ. Почему бы его и не бэкапить, скажет, раз в 2-3 дня?

Dimitry Sibiryakov
Кстати, как там в FoxPro с репликацией? Она встроенная или
обеспечивается сторонними утилитами?

Хороший вопрос. +1

Евгешка, как там с мерж репликой, транзакционной и снапшотом? :))
27 янв 09, 17:25    [6744111]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
МСУ
Fox5631
мы используем и SQLServer, и FoxPro, и Ассесс, и даже Open Office

На кой опенофис сюда приплели?
А мы еще используем интернет и клавиатуру.

Острота не по теме. Open Office позволяет создавать базы данных и формы.


МСУ
Fox5631
Система уровня предприятия 1С написана как раз на таблицах dbf и работает себе

1С уже много лет юзает sql-сервера, какие дбф? Дбф мертв, забудьте этого дедушку

Не много. Мы используем 1С 7.
МСУ
[
Fox5631

Несмотря на громкие заявления о великолепно работающих транзакциях нам удавалось несколько раз потерять данные на SQLServer.

Как кривые руки могут коррелировать с этим довольно надежным сервером? Да и версию не мешало бы озвучить.

Вот только рассказывать мне не надо про кривые руки.

МСУ
Fox5631
Потому что транзакции обеспечивают далеко не все.

Ясное дело. BOL пробовали читать перед тем, как садиться на транзакте писать?

Для ясности: был использован стандартный клиент ADP на Access. Источник данных – хранимые процедуры и View SQLServer2000 enterprize.
В первом случае неисправное сетевое оборудование приводило к тому, что один и тот же запрос постоянно возвращал на клиент разное количество записей. Вот так вот просто. Открываешь запрос – там 1500 записей, через 5 минут открываешь его же – 1000.
Проблема решена полной заменой сетевого оборудования.

Во втором случае накрылся винт на сервере. Во время не заметили. В результате и в основную базу и в бэкап данные записались с дырами. Потом сидели неделю, вручную восстанавливали.
Ну и где ваш сервер с транзакциями?!!!!!!!

МСУ
Fox5631

Естественно, в FoxPro процент потерь будет выше и мороки больше, но для огромного количества задач возможностей FoxPro вполне достаточно

Какой коэффициент потерь, Вы о чем? Какие потери в sql-сервере? Может, у Вас потери в прямолинейности рук?

Хамить мне не надо.
27 янв 09, 17:57    [6744315]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
locky
Fox5631
И что? Там и другие варианты есть. Клиент Си, данные dbf.

Осмелюсь спросить - каким боком относится сишное приложение, ходящее к dbf - и VFP?


А как это сишное приложение работает с dbf? Изобретен какой-то другой способ работы кроме драйверов ODBC или OLEDB провайдеров, которые предоставляют сишному приложению механизм обработки данных xBase.
27 янв 09, 18:01    [6744338]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Изопропил
МСУ
Бывает полное, бывает дифференциальное, бывает добавочное, бывает пофайловое.

и это всё в фокспро

Команда Copy в FoxPro присутствует.
27 янв 09, 18:05    [6744357]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
locky
Eugenkru1
Молодец Fox5631! Наконец то умный человек появился. Сразу видно что Fox5631 реально работал с серьёзными проектами.
Foxpro действительно подходит для огромного круга задач!
Во первых у Foxpro есть ....
Во вторых у Foxpro есть ....
В третих Foxpro удобен ....

А если я позвоню прямо сейчас - мне дадут совершенно бесплатно вот эту удобную сумку для переноски фокспро и я смогу брать его с собой на дачу, в отпуск.... И брошюрку с уникальными рецептами - дадут?


Я ношу FoxPro на флэшке. Занимает около 100 МБ. Инсталяции не требует. Рантайм бесплатен.
27 янв 09, 18:10    [6744377]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Dimitry Sibiryakov

Кстати, как там в FoxPro с репликацией? Она встроенная или
обеспечивается сторонними утилитами?


Репликации нет.
27 янв 09, 18:11    [6744382]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Yo.!
Guest
Fox5631

Во втором случае накрылся винт на сервере. Во время не заметили. В результате и в основную базу и в бэкап данные записались с дырами. Потом сидели неделю, вручную восстанавливали.
Ну и где ваш сервер с транзакциями?!!!!!!!

дык, если не прочли документацию чего на сервер то пинять ... хотя даже без документации и скл, это какой квалификацией нуна обладать складывая бэкапы не важно чего на тот же диск что и система ? мало того, туда же и транзакшен лог сложить ...
Fox5631

А как это сишное приложение работает с dbf? Изобретен какой-то другой способ работы кроме драйверов ODBC или OLEDB провайдеров, которые предоставляют сишному приложению механизм обработки данных xBase.

встречный вопрос, а вы про Unix совсем ничего не слышали ? на свете существует как бы с десяток либ под разные ОСи знающий dbf формат. к стате а dbf формат вообще foxpro случайно не позоимствовало у старших собратьев ?
Fox5631

Команда Copy в FoxPro присутствует.

а команда "выгнать всех пользователей" которые на оровне ос открыли дбф файлик, чтоб получить копию дбф, а не набор мусора в фокспро уже появилась ? ;)
27 янв 09, 18:24    [6744455]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

Откуда:
Сообщений: 103
фошысд
Гы))) Транзакции не нужны типа. Ржунимагу.

фошысд, что ты понимаешь под словом Транзакции?
Was verstehst da uberhaupt? фошысд, Partisanen werden dich abschlachten.
Du kannst mich jede Zeit gerne am Arsch lecken.
Изопропил, начальство приказало работать на своей программе, но рабочий персонал сверяет цифры по моей программе - на всякий пожарный и я их не заставляю, на трубе просто всё очень строго.
По поводу того что DBF умер это абсолютная глупость. Умереть может программа но не формат данных. А JPEG случайно не умер? А-то может он тоже состарился?
Ozi Explorer для GPS кто-нибудь юзал? В каком формате файл Names? Не в DBF?
МСУ, тебе уже два человека объясняли, что такое Rushmore!
Ты читал Дональда Кнута? Ты изучал классические алгоритмы поиска по бинарному дереву?
Нет? Как тогда такому твердолобому как ты объяснить ещё что алгоритмов поиска по бинарному дереву есть целая куча? МСУ, Rushmore это особый, быстрый алгоритм поиска! Но тебе чтобы понять это нужно ещё лет 20.
Вообще уже надоело отвечать на глупые комментарии. Fox5631 уже и не хочет писать и мне тоже надоело.
Не нравится Visual Foxpro 9? Конкретно что не получается, чем не нравится?
Предложите что-то лучше. А болтунов мы уже видели.
27 янв 09, 18:45    [6744548]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54840

Fox5631
Репликации нет.

И как же в нём тогда получить горячий резерв на случай затопления
серверной и прочих неприятностей масштаба предприятия? С нормальными-то
СУБД всё просто: сказал им реплицироваться в резервный ЦОД, они и гонят
данные...
Неужели судьба всех налогов страны находится в руках одного (нет, лучше
двух) водопроводчиков?!?

Posted via ActualForum NNTP Server 1.4

27 янв 09, 18:52    [6744574]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Favn
Member

Откуда:
Сообщений: 585
Fox5631
Во втором случае накрылся винт на сервере. Во время не заметили. В результате и в основную базу и в бэкап данные записались с дырами. Потом сидели неделю, вручную восстанавливали.
Ну и где ваш сервер с транзакциями?!!!!!!!
Если "сервер с транзакциями" был настроен правильно, т.е. бэкапы и логи (не стираемые) хранились отдельно друг от друга и от самой базы, достаточно было бы просто восстановить последний правильный бэкап и накатить на него логи до нужного момента времени. Это совсем недолго, и возможно именно на правильном "сервере с транзакциями" :)
А "Не заметили накрывшийся винт и данные записались с дырами" - это сильно! Я не настолько низкого мнения о MS SQL - все-таки осмелюсь предположить, что с настройками, уж по крайней мере оповещения, было что-то не то.

Fox5631
А как это сишное приложение работает с dbf? Изобретен какой-то другой способ работы кроме драйверов ODBC или OLEDB провайдеров, которые предоставляют сишному приложению механизм обработки данных xBase.
Позвольте напомнить, что dbf - это формат сишной библиотеки dbase (собственно, DBase File), работу с которой под Dos Вы, видимо, не застали. И тогда не было ни Windows, ни тем более ODBC с OleDB. А вот работа с dbf с помощью SQL была изобретена куда позже, и, кажется, лучше бы этого не делали - у многих от этого путаница, не могут отличить систему с файловой индексацией от РСУБД.
27 янв 09, 18:55    [6744584]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Favn
Member

Откуда:
Сообщений: 585
Eugenkru1
По поводу того что DBF умер это абсолютная глупость. Умереть может программа но не формат данных.
Вот именно как простой, всем известный формат данных, он и жив. Для обмена данными. А использовать этого пращура для хранения и обработки данных в 21-м веке в новых проектах - глупость, конечно, не абсолютная, но вполне так асимптотически к ней стремящаяся. :)

Eugenkru1
Ozi Explorer для GPS кто-нибудь юзал? В каком формате файл Names? Не в DBF?
Ты читал Дональда Кнута? Ты изучал классические алгоритмы поиска по бинарному дереву?
Нет? Как тогда такому твердолобому как ты объяснить ещё что алгоритмов поиска по бинарному дереву есть целая куча? МСУ, Rushmore это особый, быстрый алгоритм поиска! Но тебе чтобы понять это нужно ещё лет 20.
Превосходный пример солидной БД!
И про Кнута - браво! Жду с нетерпением мат. обоснования великого и ужасного Rushmore! Только извольте как у Кнута, раз уж упомянули, а не восторженными воплями. Кстати, чуть больше 20 лет - как раз возраст dbf. "Твердолобый" в этой связи порадовал.
Eugenkru1
Вообще уже надоело отвечать на глупые комментарии. Fox5631 уже и не хочет писать и мне тоже надоело.
Очень жаль, что надоело. Давно так не ржал. Может, все-таки еще что-нибудь, на бис?
Eugenkru1
Не нравится Visual Foxpro 9? Конкретно что не получается, чем не нравится?
Предложите что-то лучше. А болтунов мы уже видели.
А почему он должен кому-то нравиться? Кто здесь не видел файл-серверных систем и не наелся их "достоинств" в свое время? Эх молодость, молодость...
А предложить - пожалуйста, если знать, кому и для чего.
А что болтунов видели - это, да! Ну, не то, чтобы видели, но уж читали с большим удовольствием! Еще пишите, пожалуйста. Особенно про "особый, быстрый алгоритм поиска"!
27 янв 09, 19:36    [6744728]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
Eugenkru1

МСУ, тебе уже два человека объясняли, что такое Rushmore!

Тема не раскрыта.
27 янв 09, 19:45    [6744742]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Fox5631

Я ношу FoxPro на флэшке. Занимает около 100 МБ. Инсталяции не требует. Рантайм бесплатен.

Вообще-то намек был на телемагазины с их характерной лексикой и построением фраз, но это уже неважно.

По поводу "накрылся винт" и "где ваши хваленые транзакции" - плакалъ (С) всей душой.
Хотя, имхо, более впечатляющей была бы история про пожар, и как "транзакционность не спасла данные от потери".
Впрочем, я бы не отказался от истории, как в этом же случае выжил фокс
27 янв 09, 19:48    [6744749]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Изопропил
Eugenkru1

МСУ, тебе уже два человека объясняли, что такое Rushmore!

Тема не раскрыта.

Бог с ним, с рашморей.
Наскоко я понял, это слияние двух (или, возможно - большего) количества индексов. Всякие там битмаски и прочая.
А как у нас дело обстоит с тем, кто и как, собственно, решает - какие индесы нужно использовать и сливать, в каком порядке объединять таблицы, какие объединения использовать и т.д.
Собссно - как у нас дела с оптимизатором, в фоксе то?
27 янв 09, 19:50    [6744752]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
Rushmore

Rushmore is more than a technology, it's a myth. This shouldn't stop us, though, from figuring out what's behind that myth. Especially with this topic it's important to distinguish facts from fiction. In the past decade the rule was to create an index on DELETED(), just the opposite is true in this decade. None of both, however, is really the truth.

The reason for Visual FoxPro's performance has two foundations. One foundation is Rushmore, the other foundation is the truly aggressive usage of the cache. The performance difference to other databases with bitmap centered search algorithm (as Rushmore is one) is mostly not caused by Rushmore, rather due to its caching strategy and an optimized network access.

Rushmore is a bitmap oriented algorithm. Visual FoxPro creates a list for every condition that can be optimized with Rushmore. This list determines if a record fulfills the search criteria or not. Visual FoxPro uses a single bit for each record, as there are only two possible states for each record. Eight records fit into one byte. If you have an 8-million-record table, each search condition takes up 1 MB of memory.

Every bit starts as being 0 – not set – and the corresponding record is therefore in the result set. Once the bitmaps have been determined for all conditions, those bitmaps are bitwise combined. If you use the following condition in a query:

NAME = "Smith" AND InvoiceDate < DATE()-60

This query results in two independent bitmaps being created that contain all the records for "Smith" and all the records with an invoice date less than 60 days ago. In each map it doesn't matter if the other condition is not fulfilled. After that both bitmaps are bitwise combined with AND. The result is a bitmap that only has a bit set for those records that fulfill both conditions. It's not hard to imagine that memory usage to build up these bitmaps can quickly grow and slow down a query. If you only have a single condition, you can use the old dBase style:

SET ORDER TO RequiredIndex

SEEK Value

SCAN WHILE Field=Values

* do something

ENDSCAN

In many cases this is even faster than a Rushmore optimized query because Visual FoxPro doesn't have to create a bitmap. On the other hand, this technique doesn't use the cache in the same way as Rushmore does making repeated queries to the same data faster in Rushmore. Rushmore works much like the SCAN loop above setting the bit inside the loop.

How is this bitmap really created? The most important factor is that the index in Visual FoxPro is stored as a b-tree, a balanced tree. Every node is a 512 byte block that may contain up to 100 pointers to subordinate nodes. The nodes close to the root refer to key values, only leaf nodes refer to records. Because every node does not refer only to two other blocks, as one might have thought, the hierarchy in the index file can usually remain very flat. Additionally, all nodes are linked horizontally.

When Visual FoxPro searches a value, it navigates through the tree vertically top to down until it found the record. Then it continues to read horizontally as long as the search value matches the one in the index. This strategy of reading down and sideways reduces the number of index nodes it has to read, but increase the number of nodes to change when updating the index. While reading horizontally, Visual FoxPro sets the corresponding bit for each record found. This is possible because the index entry contains record number as well as key value. Data is stored compressed though. This is how the equal operator works.

Other operations work in a similar fashion. For instance, if you want to find records that are not equal, Visual FoxPro starts out with a bitmap in which all records are set. Then it performs the same search as when searching for equal records except that it clears bits when it finds a record. When searching for less or greater than, it simply keeps reading the list to the right or the left until FoxPro reaches the end of the file.

With Rushmore Visual FoxPro can determine which records are not in the result set, not which records are in the result set. That's why the Rushmore phase is followed by a post-scan phase. Every record that has been determined by Rushmore is read completely from disk. Without an optimized expression these are all records in all tables. Each of these records is then checked for the remaining unoptimizable expressions. Additionally, all optimizable expressions are evaluated once again, as someone else might have change the record while Visual FoxPro created the map. Therefore a result set might not contain all records that currently match the search criteria, but you never get records that do not match the search criteria.

There's one exception from this rule, tough. When counting records, Visual FoxPro tries to avoid the post-scan phase. When the bitmap has been built and no unoptimizable expressions are left over, Visual FoxPro starts counting the bits set. Therefore COUNT FOR and SELECT CNT(*) FROM are extremely fast if a query is fully optimized. A partial optimization is not sufficient. It also doesn't help to use any other counting method like SELECT SUM(1) FROM…

When creating the bitmap Visual FoxPro has to read all index blocks that meet the search criteria. Repeated access makes Visual FoxPro retrieve these blocks from the cache. However, the cache is discarded, if one station changes an indexed field or adds a new record. Visual FoxPro can only determine that another work station had changed the index, but not what exactly had changed. Therefore the entire cache is discarded. You can exploit this to measure performance. By using a second instance of FoxPro that replaces one index field in the first record in a loop.

Some time ago people started to realize that an index on DELETED() is not always the optimal solution. It appears that there's kind of an anti-movement completely condemning the index, which is also not a good idea. Whether Rushmore is a good idea is actually quite easy to determine. If you read more bytes in the index file than you remove in records during the post scan, Rushmore decreases performance. You have to compare the bytes that are actually transferred.

You therefore need to keep in mind that the cache has an impact with Rushmore and that CDX indexes are stored compressed. Equal beginnings of a word are stored only once. The actual amount of data can be determined with the system monitor in Windows. Even more precise results are possible with a network monitor such as NETMON.EXE which comes with Windows 2000 server, or Ethereal which is available for free from http://www.ethereal.com. Such a network monitor reveals which part of a file is actually read. Combined with the structure of the files from the help file you can determine lots of details.

If an application changes lots of data this more frequently invalidates the cache. Hence, such an application benefits way less from Rushmore than, for example, a CD catalog application that has put all data into the cache after a short time of using it.

If your application has many deleted records it also benefits from Rushmore. If your application visits a record multiple times because, for instance, the algorithm requires navigating to the next and previous records, Rushmore is superior as it can reuse the bitmaps while old-style xBase code has to re-read all records over and over.

If you want to determine the number of hits before actually executing the query giving your users a chance to avoid long lasting queries, your query should be fully optimizable. This gives you a real speed advantage as creating a bitmap takes significantly less time than reading the entire table, and the bitmap can even be reused should the user decide to execute the query.

Another important factor is the distribution of values in the indexed field. There's a huge difference if you search for a unique value like a primary key or in a status field that only can take ten different values. An extreme example is the index on DELETED() for which usually all fields have the same value. In general you should avoid such indexes unless you need them for counting purposes.


http://www.foxpert.com/docs/howfoxproworks.en.htm
27 янв 09, 20:05    [6744780]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
locky
Fox5631

Я ношу FoxPro на флэшке. Занимает около 100 МБ. Инсталяции не требует. Рантайм бесплатен.

Вообще-то намек был на телемагазины с их характерной лексикой и построением фраз, но это уже неважно.

По поводу "накрылся винт" и "где ваши хваленые транзакции" - плакалъ (С) всей душой.
Хотя, имхо, более впечатляющей была бы история про пожар, и как "транзакционность не спасла данные от потери".
Впрочем, я бы не отказался от истории, как в этом же случае выжил фокс


Ну если для работы сервера с чудо-транзакциями нужно, чтобы верхом на нем сидел администратор,
то это, конечно, стоящее дело.
В FoxPro мне никакой администратор не нужен. Все, что требуется, я делаю из программы.




Теперь, что касается резервного копирования. Мне не нужно в FoxPro выгонять пользователей из программы, чтобы одной из множества команд копирования сделать бэкап.
Содержимое бэкапа при этом меня устраивает.
Про dbf, открытый на уровне ОС, не понял. Зачем мой dbf кто-то будет открывать на уровне ОС.
Это моя база. С ней работают мои программы.
27 янв 09, 20:41    [6744864]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Yo.!
Fox5631

Во втором случае накрылся винт на сервере. Во время не заметили. В результате и в основную базу и в бэкап данные записались с дырами. Потом сидели неделю, вручную восстанавливали.
Ну и где ваш сервер с транзакциями?!!!!!!!

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

База и лог, да были вместе на сервере. Бэкап – в другом месте. Ну что толку? Он уже был затерт данными с дырами.
Yo.!
Fox5631

А как это сишное приложение работает с dbf? Изобретен какой-то другой способ работы кроме драйверов ODBC или OLEDB провайдеров, которые предоставляют сишному приложению механизм обработки данных xBase.

встречный вопрос, а вы про Unix совсем ничего не слышали ? на свете существует как бы с десяток либ под разные ОСи знающий dbf формат. к стате а dbf формат вообще foxpro случайно не позоимствовало у старших собратьев ?

С Юниксом не работаем, про библиотеки знаю. И при чем тут они?
27 янв 09, 20:49    [6744887]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
Fox5631
Мне не нужно в FoxPro выгонять пользователей из программы, чтобы одной из множества команд копирования сделать бэкап.
Содержимое бэкапа при этом меня устраивает.

Поделитесь технологий , как вам удаётся от начала копирования до конца запретить запись в dbf файлы другими экземплярами вашей же программы?

Если удаётся, то пользователи, желающие что либо записать в базу во время бэкапа курят бамбук?
27 янв 09, 20:51    [6744894]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Какой-то прямолинейный тролль, неинтересно как-то
Или (упаси боже) - он таки реальный пипель?
Не верю! (С)

-------------------------
There’s no silver bullet!
27 янв 09, 21:03    [6744916]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Favn
Fox5631
А как это сишное приложение работает с dbf? Изобретен какой-то другой способ работы кроме драйверов ODBC или OLEDB провайдеров, которые предоставляют сишному приложению механизм обработки данных xBase.

Позвольте напомнить, что dbf - это формат сишной библиотеки dbase (собственно, DBase File), работу с которой под Dos Вы, видимо, не застали. И тогда не было ни Windows, ни тем более ODBC с OleDB. А вот работа с dbf с помощью SQL была изобретена куда позже, и, кажется, лучше бы этого не делали - у многих от этого путаница, не могут отличить систему с файловой индексацией от РСУБД.


Ну, в таком случае и FoxPro сишная программа (написанная на Си).
Вот, и это вы не застали, как я работал с dbf под Dos.
С FoxBase, правда, не сталкивался, но в ДОСовском FoxPro работал. SQL был.
По досовскому dBase где-то книга у меня валяется. Читал давно. Про SQL не помню.
Я и сейчас могу открыть dbf каким-нибудь редактором и править его напрямую.
Впрочем, также, как и любой файл SQLServer…
DBF тут не лучше, и не хуже, чем все остальное.
27 янв 09, 21:04    [6744918]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
locky,

мотивация слабопонятна.
27 янв 09, 21:04    [6744919]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Изопропил
locky,
мотивация слабопонятна.

Дык, скучно....
Когда тут в последний раз рубилово было? Года 2 назад?

Вот и решил кто-то шапитой сюда приехать - всё-таки веселее....
27 янв 09, 21:06    [6744922]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 75   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить