Lets talk databases!

[derby]

I've split the database so that as many users as needed can use it without any problems.

there's something to be said for ingenuity....

however, there's also something to be said for using the right tool for the job. 

[Monster Dave]

Two things FWIW:

1) I can only use the tools at my disposal.
2) I can only use the tools that I know how to use.

We don't use Oracle, so that's not even a consideration. I do use SQL to some degree - but I know how to best integrate a slick GUI with Access. There's no sense in changing what's already been built to accommodate SQL as a back-end unless there was something major in the pipeline to warrant that sort of a change.

[derby]

I do use SQL to some degree - but I know how to best integrate a slick GUI with Access.

who says you can't use access as a front end for a sql database?  

There's no sense in changing what's already been built to accommodate SQL as a back-end unless there was something major in the pipeline to warrant that sort of a change.

well, the "right time" for that was probably when you broke it out into multiple databases to prevent issues with locking.

not that what you've done is "bad," just the further down that road you go, the more work it's going to be when you eventually have to move it to SQL. 

(just speaking from ~20 years of IT experience)

[ducpainter]

who says you can't use access as a front end for a sql database? 

Two things FWIW:

1) I can only use the tools at my disposal.
2) I can only use the tools that I know how to use.

We don't use Oracle, so that's not even a consideration. I do use SQL to some degree - but I know how to best integrate a slick GUI with Access. There's no sense in changing what's already been built to accommodate SQL as a back-end unless there was something major in the pipeline to warrant that sort of a change.

teach him massah derby...

[derby]

teach him massah derby...

hehehe...

[ducatiz]

well, the "right time" for that was probably when you broke it out into multiple databases to prevent issues with locking.

not that what you've done is "bad," just the further down that road you go, the more work it's going to be when you eventually have to move it to SQL. 

(just speaking from ~20 years of IT experience)

meh, i have a VB script somewhere that merges Access databases.  It requires a lot of tweaking.. I wonder if it will still work, it was for Access 97

[Monster Dave]

I really don't see what the problem is with Access. It's a very useful system and I've not run into many problems with it.

Derby, I'm sure you know what you're talking about with that much IT experience, but splitting the database wasn't anything hard and really all it did was create a bunch of linked tables from those that I had already built. A transition to SQL would have been a lot more work. It took me all of 5 minutes.

[ducatiz]

derby is offended by technological inferiority.

why use a hammer if you can use a pneumatic nail driver?  i mean, even if you only want to hang one measly little picture on the wall.  why?

[derby]

I really don't see what the problem is with Access. It's a very useful system and I've not run into many problems with it.

there's nothing wrong w/ access. it's a good tool until it isn't. 

[derby]

derby is offended by technological inferiority.

why use a hammer if you can use a pneumatic nail driver?  i mean, even if you only want to hang one measly little picture on the wall.  why?

it probably comes from the environments i've worked in. traditionally, the database admins/developers tend to use oracle/SQL and the "end-users" use access.

the access databases are usually "off the grid" without any official sanction from the MIS departments and, as such, aren't properly backed up. "we" usually find out about those when the "developer" gets in over their head and requests help from one of the (oracle/SQL) dbas or they bork it up to the point that they need to revert to a backup (which doesn't exist because "we" didn't know about it).

[Monster Dave]

Gotcha!

[ducatiz]

it probably comes from the environments i've worked in. traditionally, the database admins/developers tend to use oracle/SQL and the "end-users" use access.

the access databases are usually "off the grid" without any official sanction from the MIS departments and, as such, aren't properly backed up. "we" usually find out about those when the "developer" gets in over their head and requests help from one of the (oracle/SQL) dbas or they bork it up to the point that they need to revert to a backup (which doesn't exist because "we" didn't know about it).

and you should be thanking Bill Gates for that because it results in the perceived need to have a large IT staff on call 247.  jobs jobs jobs!