- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Have to agree with someone further up, you know very little about Access security (amongst other Access things judging by your writeup) - and what version were you using??? That article, which deals with only one aspect of security, dates back to a version of Access that was replaced in 1995...
You're right about preferring just about any other database for what you wanted to do, but there's no need to overstuff the pie...
Admin
Ok, my mistake guys (referring to the KB security issue) I finally found that particular article I was referring to, and it is not from an official MS site, so I humbly retract that statement.
And as someone claimed, I am by no means an Access or VB expert. Thank god!
Oh, and those who felt sorry for me will be glad to learn that I now have a second job while studying. I'm now working with Oracle Forms and Oracle Application Express.
I'm very much looking forward to graduation and actually working with something that isn't as "user friendly" as these tools (Forms, Access, APEX) claim to be.
Admin
I don't want to be nasty here, but the real wtf is this:
A company that exclusively uses Microsoft products hired you to do a job, and you want them to change to using MySQL and PHP?
So were you going to document a procedure for backing up and restoring their MySQL database? More likely you just wanted a tool you knew, and then after you finished the job some poor (worse paid) IT sap is left trying to apply patches to MySQL, etc.
I could go on about "A bad workman always blames his tools", but seriously: you had a programming language (VB - more lines of production code written in VB than any other language), a database (ever hear of the Data Abstraction Layer? If you'd used one the change to SQL Server wouldn't even have affected your VB Code, just write a new DAO). Why are we getting into PHP, MySQL, SQL Server?
Picture it from the IT guy's perspective: "They hired some 'College Hotshot' to write some app, the guy comes in, gets paid twice what I'm paid, and starts demanding we alter the IT landscape of the company just to make his job easier?!?! Now he's back in college, and I have to write and format reports for the business users, because they only knew how to do it in Access, and now we're using SQL Server"...
My 2 cents...
Admin
So I have to say it.
It wouldn't be hard to put an Aerostar engine in a Mustang. In fact, if the two cars are of similar vintage it's probably the same engine (thought the Mustang will have other engine options).
Now, a better analogy would be putting an F-350 diesel into a Mustang. That would be difficult, perhaps impossible.
;)
Admin
Almost forgot this:
Crazy requirements, lousy database, high-paid/low-skilled consultants, great, we've all dealt with that at some point, and that's why most of us are reading thedailywtf.
But you managed to get a company (a company which lacked the skills) to install "linuxy" software (ie, software that they don't understand) when there was no real reason? The TCO (ie, cost of hiring IT staff who can support this app) makes your solution the real wtf.
If you had something working (VB on Access), and it ran at 2mph because Access was a bottleneck, I would have liked to have read that WTF.
Admin
TheBilliardPlayer:
I was never told they exclusively used MS products until later on (when they changed their minds on PHP, and wanted me to do it in .Net, which I had volunteered at an earlier meeting). I told them that the two most obvious technologies would be ASP.Net or PHP, seeing as it would integrate with MS Live Maps.
Same with MySQL, I didn't know they already had an MSSQL Server running. When I was told, I time and time again suggested using that instead of Access at it would take care of all security, concurrency and backup issues. Coding a data abstraction layer would've taking a lot of time compared to using the upscaling wizard in MSSQL.
Admin
Ok, I'm just making these comments cos I've been here before, and I think you'll find that these types of jobs go a lot smoother when you consider where the IT and Business people are coming from, and try to work with them rather that think of them as a nuisance.
Admin
I hate these kinds of articles about Access. I'm a professional Access developer and have been for over 10 years. I would never suggest Access (or the Jet database engine) for a project like this, any more than I'd suggest that you use a hammer to put in a screw. So, nobody would disagree that Access was a poor choice as a front end to a graphically based app (that happens to be data driven).
But Access is actually a very fine front end for proper database applications. With its built-in Jet database engine (free clue: Access is a front-end development tool, not a database; Jet is the database that is Access's native engine; but Access can connect to a huge number of back ends, including SQL Server, MySQL, Oracle, anything that has drivers available that Access can communicate with, ISAMs, ODBC or ADO). There are Access front ends out there running against SQL Server with 10,000 users (and I'm talking MDB + ODBC, not ADP + OLEDB). And they run just fine and dandy.
Where people most often screw up with Access is in trying to use a monolithic MDB file for storing both data and the application front end. Now, the Jet database engine, being file-server based (and having no server-side process communicating with the clients) has limited ability to support large populations of WRITE users (it can support up to 255 read-only users). But when you exceed that, you can easily port your data store over to a server database of your choice, SQL Server, MySQL, PostgreSQL or whatever you like. If you've designed your front end application well, this won't be hard -- I usually start recommend upsizing when the concurrent user count starts exceeding 15 on a regular basis, though I design even the smallest apps with efficiency of data retrieval in mind from the beginning (which works very well when you convert to a C/S back end).
The thing that most inexperienced Access developers miss is that each user of an Access application needs an individual copy of the front end, with tables linked to the back-end data source (Jet or whatever). The reason for this is that the Access front end is a Jet MDB, so it is subject to the same user limitations as a Jet data MDB, i.e., 255 max read-only users and far fewer write users.
You may think "But the users aren't editing the forms and reports, so this would be read-only, right?" Well, no. Since Access automatically saves certain properties of forms (such as filters and sorts), the forms get written to, and when you're sharing it with multiple users, these writes can collide and cause unexpected results. Thus, it's required that every user have a copy of the front end.
Storing the app locally on the desktop doesn't seem to bother most people with apps like Excel and Word, but it seems to annoy DB developers, because they often have a web-based bias, where you have a single codebase run by everyone.
But they forget that it's not being run by multiple people, but by a single HTTP deamon -- it's only the web server that's connecting with multiple users. An Access app is a desktop application, not a web app, so the front-end app is by definition going to need to be distributed, just as with other desktop apps.
Many people who are used to sharing a front end MDB are annoyed at the "problems" this raises for distributing changes to the front end. But it's really a rather trivial problem to address, quite easily resolved by using updaters like Tony Toews's (http://www.granite.ab.ca/access/autofe.htm), or even batch files or logon scripts.
On the subject of security, yes, Jet user-level security is weak (Access itself has no security -- it gets its user-level security from the Jet db engine, and with Access 2007, the new version of Jet, called ACE and with the ACCDB file format has abandoned Jet user-level security (though you can still use it in A2K7 with MDBs)), precisely because of the file-based nature of the Jet database engine. If it's inadequate to your purposes, then you need to migrate to a back-end database engine that provides the security you require.
Again, this is not a flaw of Access -- it's a matter of choosing tools that are appropriate to the problem set.
-- David W. Fenton David Fenton Associates http://dfenton.com/DFA/
Admin
FIST!!!!!11!one!!
Admin
what a bunch of crappy decision making from a pompous noob dev
I certainly hope your pay was low
Admin
When I was in college, I wanted to get a leg over some of my fellow students too...
Admin
Sounded like an attempt of the OP to try and look like a local hero but instead appears as a total n00b. The real wtf is that he posted the story.
Admin
Screw the Access or SQL Server debate, I wanna know how World of Salescraft turned out! Can one obtain a +1 Roladex? A Palm Pilot of Protection? A cone of cold-call spell?
Don't leave us hanging!
Admin
I've been on both sides of this argument. Overall, I have to side with TroelsL. Sounds like some lazy IT guys who only want to learn one way of doing things.
Admin
Admin
SQL Express..
Admin
Admin
As we Russians say: For a bad dancer, his balls always get in the way
Admin
Admin
First they map their competition on the globe with access and encarta and then quickly destroy the competition using Ion Cannon Control plugin ;)
Admin
[quote user="Nicolas V."][quote user="SneWs"]Please tell me this is a joke, since it's just not possible to be that "dumb"!? Have to feel sorry for the poor lad trying to implement that knd of app with access and VB... vb, vb. hmmm, when ever has vb been usfull!?[/quote]
Ever heard of C# and .NET, why use a old and outdated language syntax like VB, all code written in VB.NET should be burned on the spot. ( Note, this is not anything personal, just VB'ish )
Admin
Admin
"I would never suggest Access (or the Jet database engine) for a project like this, any more than I'd suggest that you use a hammer to put in a screw."
The point of a good database is that it's good for any job and any project and programmers don't have to worry about it too much, and you don't have to hire a monkey to tinker about with some stupid toy product and tell you you're doing it wrong. You wouldn't understand how this works because you've spent ten years "developing" on and basing your career around a piece of garbage that you admit you would never even suggest for a serious project.
Admin
Admin
I disagree. You have learned everything you need/want to know about software development!!
sez he who is quitting and going back to engineering ...
Admin
Admin
"Anyway, the project is still not completed, as decision making in this company requires 5 top level executives to sacrifice a virgin goat during the second stage of the equinox. I'm still in college, 6 months away from getting my degree."
I hope your company is not situated in College Station, because executive decisions can never be made regardless of the sun's position.
Admin
Admin
Access security dates from a time when Windows and DOS had no security or user login, and has never been updated or corrected. But even so, it was never that stupid: that's just ignorance.
Admin
Admin
This is incorrect. There are some situations in queries and importing of data when only the first 255 characters on memo fields will be passed. But there are easy work arounds for the most part.
From the Access 2007 help
There are two kinds of strings: variable-length and fixed-length strings.
Sample code follows illustrating a brute force and ignorance bit of code: (Hopefully it is readable in this posting.)
Sub TestString()
Dim strTest As String
strTest = "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf & _ "12345678901234567890123456789012345678901234567890" & vbCrLf
MsgBox Len(strTest) & vbCrLf & strTest
End Sub
Tony Toews, Microsoft Access MVP
Admin
Apparently, you aren't familiar enough with MS Access to do anything constructive with it.
I've been working with MS Access for almost 8 years - nonstop in development and deployment of various applications.
While your particular project certainly was a viable candidate for using larger scale tools, if the company was on the tightest of budgets to which you suggested, an Access database front end would have worked just fine.
Your first error unless I'm misunderstanding what you are saying, that "Access VB has a max length of 512 characters" - really? I certainly can dimension a string in VBA using more than 512 characters....in fact, the literature suggests that you can dimension a (fixed-length) string variable in VBA of up to 65,400 characters! So, I'm not sure how you coded your VBA strings but you aren't doing it correctly if you think the max string length in VBA is only 512 chars...
Second issue I have with your remarks on MS Access is about security......while it may be very difficult to secure an Access database due to its inherent open architecture, it's not impossible.....just to let you know, the Shift key (called the bypass key in the literature) can be secured but you have to write code to disable it. You can also write code to hide your database window against prying eyes.....you can also write code to disable the F11 key which will otherwise show the database window....you can also disable what are called "Access Special Keys" which will further ensure security....after you do this then you disable the toolbars programmatically in a way that inhibits the user from direcly accessing them. You can also protect your code by password protecting your VBA project and/or converting your MDB into an ecrypted MDE file.
These security measures are more than enough to protect an MS Access database against the average user. However, if you need yet a higher level of security, the highest of all security measures would be to encrypt your tables (because they are otherwise open to importation into new database files EVEN with the aforementioned security measures in place).
The Rijndael encryption algorithm for VBA does exist on the web and can be successfully deployed within an Access database to scramble all table data in an MDB file.
So before you go off on a rant about how underrated and lacking MS Access is, perhaps your company should have hired an Access expert in the field instead of some hack college kid who specializes in nothing, but who's knowledge is scattered so thin throughout the IT field that no intelligently informed decision on ANY piece of technology can be accurately made.
Admin
If you'll read my previous posts, I said that I was mistaken in my statement about string length in VB, and that it came from a non-MS knowledgebase. The problem was with passing the strings.
And no, I have very little experience in Access. My quarrel with the security is this:
Access markets itself (at least as far as I have seen) as a userfriendly database/database frontend. In order to get the level of security you talk about, you need an advanced knowledge of Access. That defeats the purpose of having a user friendly piece of software.
I don't know how it is where you are located, but it would be very hard to find an "Access expert" over here, as most people who study databases for a while, seem to seek towards various other DBMS. Just an observation, not an opinion.
I've already stated that Access is fine for some applications, but I still don't think this was one of them.
And as I've also already said, the (original) WTF was not really about Access, but more about insisting on using Access for months, then after a single comment from a network admin, changing to MSSQL, meaning that those months of work were more or less wasted.
I still don't like Access. Because I am simply not the target audience of it. I prefer writing my own SQL over building it with a GUI-based query builder. SQL is the same (or should be, anyway) across most DBMS (even Access), and instead of learning to find my way in a GUI-environment, it is easier for me to find a connection string for whatever DBMS and programming language I'm using, and just use the SQL I'm already used to.
It's all a matter of taste, but I know I'm hardly the only developer to prefer other technologies to Access by default.
Admin
coding a DAL is pretty simple these days... there are nice projects out there like subsonic or data access application block
Admin
Well..., this shift thing can be disabled. There is a per-.mdb file setting for that. I suspect users can press CTRL+G anyway and hide the said field programmatically from the debug console anyway.
Admin