dbworks: samba is not supported...

...is it possible? not IMNSHO.
today i've spent more than half an hour with the support because in
the last weeks dbworks give us plenty of sql errors of the "S1000"
family. they're related to problems when writing to a file "wrong
bookmark", "missing record", "cannot delete record" and so on.
we've been using a samba file server since 1998 and never had a
problem. we've recently --few months ago-- upgraded to samba 3 due to
a number of reasons and haven't had problems with that. from few weeks
ago on, we've begun getting all these S1000 errors, which make swx
crash and don't let us work.
all i've been able to be told is that dbworks doesn't support samba:
"a standard microsoft is required".
first question: what's a microsoft standard?
second question: we can't move to a san/nas because it doesn't carry a
windows server?
third question: why did it run flawlessly --well, flawlessly... let's
say it ran-- until now and now gives us problems witnout having
upgraded/changed anything?
*i'm* the sysad and know nothing changed in the last few months.
no read only files --"create mask = 0777" in smb.conf and chmod'ed -R
0777 our shared directory--, no restrictions on shared directories.
anybody could delete the whole tree without any control.
at the moment we're still using .mdb file, which is something around
15mb after "tools/compact database" in access.
next week i'm moving to msde, but i have to arrive at next week still
alive and with 4 engineers working.
any advices?
thanks in advance.
Reply to
Gianni Rondinini
Loading thread data ...
I have an email from dbworks saying they do support Samba.
The question is what has changed? Have you looked in the logs to see what is really happening? What is issuing the S1000 errors?
This just popped up in a google search. You could be having a MSoft problem. Did it start after some automatic update from MSoft?
formatting link
Reply to
Hi, Linux/Samba environmment is not directly supported by MechWorks (DBWorks makers).
We have few customers that succeeded in making the system work properly, but we are not able to provide technical support
on that topic, so every issue has been solved by the customer himself.
We've already had notifications about problems with such systems, even with applications other than DBWorks.
Anyway, we discourage the use of MDB as database, because it raises problems even in MS enviroment...
You can contact us for further information. tel: +39 051 582294 snipped-for-privacy@mechworks.com
Kind Regards, Luca Maselli MechWorks support
Reply to
Luca Maselli
and this is reasonable, because it's not your own software. but the point is: since we're talking only of a file sharing server --and not an application/database server--, i can't see how it can give problems with accessing the files. i mean: we have 20.000+ swx files on the server we're accessing with no problems and we've been using samba file sharing server for 10+ years without problems, then i don't see how it can be the problem.
and, again, this may be ok when somebody can't access files, but it's not our case. during yesterday, i moved all the dbworks directory to a windows xp professional pc --one of our workstations-- and this didn't solve the problem --as it was reasonable to expect--. then i guess it's not samba but something else with dbworks --that both us and people at nuovamacut hasn't been able to figure out yet--.
upgrading to msde is scheduled for next week, but there are still 3/4 working days before and i'd like to understand what's happening.
i'm talking with people at nuovamacut at the moment, but i'll drop you a mail with our .mdb file so you can have a look at it. we'll probably hear by phone later this morning.
Reply to
Gianni Rondinini
nice to hear this --expecially because modern san/nas often carry a linux+samba--.
apparently nothing. i mean, nothing i'm aware of --and since i'm the sysad and the only one that can install software on our servers, i'm pretty sure they're exactly as i installed--.
in samba logs there is nothing about these errors. sometimes i get this error [2005/06/23 10:27:08, 0] lib/util_sock.c:get_peer_addr(1150) getpeername failed. Error was Transport endpoint is not connected in /var/log/samba/smbd.log, but the hour of the error is not the one we've getting the s1000 access error.
saving assemblies --until yesterday: today we're getting errors also with some parts yesterday worked well--. there are different s1000 errors: invalid bookmark, missing record, ...
this is possible: we have automatic updates from microsoft for xp pro but we don't see when they're installed because the system does it automagically. it is possible that problems came out with an update. that webpage is interesting, but we're using an access file and its odbc driver, but the page relates to the sql driver.
Reply to
Gianni Rondinini
Just thought I would jump in here and mention that we are running off a SAN very well. And from what I understand SAN and NAS are two very different creatures. You are right that NAS is often Linux/samba but can also be windows just as easily. What I know about SAN is that it is certainly not by itself either but needs a head to it that talks the fiber channel language. In our case we have a windows box that has a drive that is the SAN, this drive is shared out using standard windows technology as you put it for the rest of the company. But if we had a Linux head to it we could also share it that way. I have been amazed at the speed increase even over really fast SCSI drives by doing this. And then the disaster recovery is amazing as well. But then I think you are using NAS and not SAN technology here.
My guess is that the access database is the issue. There is no way I can see people using that over 2 people as I know there are a ton of limitations to access. So my thought is leave the solidworks files on the NAS or whatever share and get the database shared from another machine (windows) if it is only 15 meg. I really bet that you are not on a SAN as if you were you would most like also be running full SQL or Oracle. We run SQL and have about 60 users hitting it with no issues. I would really encourage you to try to get at least to MSDE.
I know there have been issues with file locking and those type of things in SAMBA in the past. Something like that might have resurfaced or you might just be getting close to the issues in access databases too either size or number of users.
--Matt Feider
Gianni R...stuff deleted...
Reply to
Matt Feider
Which pretty much rules out a Samba error. You will have to look elsewhere.
The S1000 errors are issued from the database engine dbWorks is running under. As I understand the database files and the database engine will be running on a Windows server. Only the SW files will be stored on the Samba server. Again the finger points at MSoft.
You can do a rollback if you are running XP on the server.
Reply to
thanks to all of you for your pointers and suggestions. after quite a bit of phone calls, people at my var's have been able to fix our database, that got corrupted somewhere somehow.
i'm waiting for further details from them and in the meanwhile will go on setting up msde for our environment.
for who asked this, we're not running san neither nas: we simply have a linux box with a bunch of 10krpm cheetah drives in raid5 + a hot spare, but we plan, someday, to move to, at least, a nas, which probably will have a samba onboard.
Reply to
Gianni Rondinini
I would like you to make something clear to me. When you say your database got corrupted, the database you are referring to is running on a Windows operating system. Is this correct? If so, which Windows operating system are you running the database on? Is it a workstation or server version of Windows?
Reply to
before answering your questions, let me tell you the news. the latest thing that came out seems ridic^Wstrange, but at the moment works. preface: the phone support supposed our database got corrupted *or* contained some errors. at the moment, we're still using a shared .mdb access97 file which is located onto a samba 3.0.xx file server. i emailed a zip containing the .mdb to people at my var, they converted it to access2002 file format and now seems to work --or, at least, doesn't give us any problem--.
then, it wasn't my db that was corrupted or damaged, but for some unknown reasons it was probably the old file format that gave us those errors.
let's see and hope... Gianni Rondinini VBR - Vero Birro Romagnolo
Reply to
Gianni Rondinini

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.