Sybase to Access

[codercode]

I'm working on a Visual Basic .NET using Access database. However, my
client already have a 30MB database with Sybase ASA and Sybase is way
too much for that. Is there anyway I can migrate from a Sybase to
Access? or is it possible at all. If it is not, can these two databases
co-exist together?

 

[vbnetdev]

see

http://72.14.205.104/search?q=cache...base.pdf+.NET+sybase&hl=en&gl=us&ct=clnk&cd=3

 

[Cor Ligthert [MVP]]

Are you ending your career with that client, advising Access, while there
are 2 free SQL servers which do a better job?

Just my thought reading your message,

Cor

 

[vbnetdev]

LOL

Are you ending your career with that client, advising Access, while there
are 2 free SQL servers which do a better job?

Just my thought reading your message,

Cor

 

[aaron.kempf]

I agree.

Anyone using MDB for __anything__ in the year 2006 should be fired and
then spit upon

-Aaron

 

[Master Programmer]

Access is a toy for storing "My CD Collection" or "My Favourite
Ponies". It is not a DB in any sense that that term "DB" is usually
used
in a professional environment.

****ing grow up and use SQL Server.

The Grand Master

 

[aaron.kempf]

Master;

Oh I fully agree.
But Access is also a replacement for Crystal Reports.. Access Data
Projects are a very powerful alternative; no DLL hell to play with.

Just simple bound forms.. much much better than VB6; but it's the same
architecture so it's all good

I hate MDB with a vengence.
But ADP is a great way to keep VB6 code without rewriting it.

We're a fully supported platform for VB6 ADO code against SQL Server.
you should check it out sometime..

-Aaron

 

[Master Programmer]

Aaron

Have you used database encryption for SQL Server before?

The Grand Master

 

[aaron.kempf]

to encrpyt text or the connection string argument?

ADP supports both without a problem

-aaron

 

[aaron.kempf]

like for passwords and stupid stuff like that?

yeah I've got a couple of functions to do it; i just dont know if i see
the point.

encryption within a database is ****ing pointless.
you just can't use SQL authentication for ANYTHING on ANY SERVER and
you're fairly secure-- out of the box

-Aaron

 

[aaron.kempf]

and of course you need 'trust for delegation' and setspn

 

[Master Programmer]

Its the IT dept thats not trusted. They must not see the data. Think I
will just have to encrypt the fields that are sensitive.

The Grand Master

 

[Master Programmer]

At then end of the day the windows authentication system is that easy
to crack if they have physical access, that the only option seems to be
to encrypt the fields using the program

The Grand Master

 

[aaron.kempf]

windows authentication isn't easy to crack if they have physical access

sql authentication is 'impossible to secure'

but that doesn't make windows authentication impossible to secure

how are you going to crack in.. guest accounts? escalation due to trust
of the network account?

I dont let anyone hit the database; they can all do read only through a
cube for all I care

-Aaron

 

[Master Programmer]

Windows authentication is childishly easy to crack if you have physical
access to the box. There are lots of brute force crackers availble,
they work offline on the SAM file containing the users/passwords. I
bought a used dell box a while ago and didn't have the password. I
found a web site that allows you to boot your PC from a floppy, it then
grabs the sam file and saves it to the floppy. Then you upload the
file to the web site and 24 hours later they send you all of the
usernames and passwords. There are other methods too, including
downloadable ISO files allowing you to create a CD that has a bootable
linux and a brute force cracker and dictionary.

The Grand Master

 

[aaron.kempf]

having physical access to the computer is different than having
physical access to the computer.

and for the record; I use 15-16 character passwords everywhere I go..
_not_ crackable

-Aaron

 

[aaron.kempf]

yeah we had to sniff the password hashes for customers.. and then we
had to do this for a couple of hundred clients-- so that we didn't
force them to reset their password

not rocket science.
databases can make pretty easy work of it

but it's not practical.

being able to take a server home-- and use brute force and a year to
crack my password:

a) i'll have changed passwords by then
b) you still get a bunch of candidate keys... if you get a hit on my
hash; and you try 10 of them; then you have a trail of failed logons
c) this doesn't mean that Windows NT authentication in a typical
network setup is 'impossible to secure'

Windows NT authentication is _WONDERFUL_ in SQL Server.

and _NO_ it should not be the single logon method for windows apps--

but altogether it is pretty powerful; pretty secure.

I just can't stand SQL Authentication.

70% of the clients I've had in the past 10 years use SQL
Authentication.. that is just flat out ****ing ridiculous.

I wish that everyone used mySql-- then you could secure it so that
you're only getting hits from a particular IP address.

it makes a lot of sense; they should really duplicate that
functionality in SQL Server.

-Aaron

 

[sstory]

Not sure of the question.

1.) Access would really bite with a 30MB database--not recommended.
2.) Access could use link tables to link to Sybase perhaps and give you
"access" to it. then again, why would you use Access if that were possible
instead of just getting the drivers to connect directly to Sybase.
3.) If it is a problem you might consider migrating to MySQL.

 

[RobinS]

Why would Access bite with a 30MB database -- that's nothing.
I've had apps with an Access database that was 500MB, and the
performance was fine.

It would be better to migrate to SQLServer Express, but using
Access won't kill him.

Robin S.
---------------------------------

 

[aaron.kempf]

I've had Access apps with 25 mb of data that can't support a half dozen
users.

MDB shouldn't be used for a single user nor a single record.

If MS had a decade-long policy of preaching SQL over MDB then _MAYBE_ I
would be willing to accept SQL 2005 _CRAP_ that is built into VB 2005.

As it is; I can't reccomend SQL 2005 _anywhere_ since it's not
supported on TRANSMETA (_BLADES_ and tablets), it doesn't support SQL
Agent; and it doesn't support replication like MSDE 2.0 did

-Aaron