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.

 

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?

http://support.microsoft.com/kb/q175313/

 

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


Kind Regards,
Luca Maselli
MechWorks support

 

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.

regards,

 

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.

regards,

 

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 Rondinini wrote:
....stuff deleted...

 

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.

 

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.

regards,

 

Gianni,

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?

 

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

 

Thanks Gianni. Pretty interesting.