[RESOLVED] What languages are databases back-ends created in

[Nightwalker83]

Hi,

I have seen several thread on here saying that you can create a database in a programming language such as Java, C#, VB6, VB.Net without the use of references to built-in or third parties files such as Access, Oracle, etc. My point is that you can not and I have not seen any evidence suggesting otherwise. So that being said what languages are the programs such as Access, Oracle (other database back-ends) written in?

Thanks,


Nightwalker

[dilettante]

I can't think of any reason why you couldn't use just about any programming language you wanted to. There are practical reasons that could dictate your choices of course, and those depend on the characteristics your "database back-end" needs to have.

But I'd guess nearly all PC DBMSs are written primarily in C++ with some assembly language here and there.

Outside of the Windows/Mac/*nix PC arena the possibilities are far more open. Remember, there are machines where C is only supported in a fashion similar to VB3 or VB4 before native code compilation was even possible. Nobody uses C for serious work there and C++ may not even exist.

[Nightwalker83]

I was under the impression that you could not use VB6, etc, although, it turns out that I was proven wrong in one respect, see Database in VB6. However, while the VB6/VBA code that dee-u links to can create a .mdb (Access Database) would that type of database still be able to be created or used if Access were not referenced to in the project in some or Access being on the development machine?

[si_the_geek]

A .mdF is a different kind of database (SQL Server), and a .mdb is not actually an "Access" database (Access is just the best known program for using them).

As for whether or not a particular language could be used to create a database, all it needs is the ability to read/write files, and store data in memory (arrays etc), and be able to communicate with other programs somehow. Everything else is just a matter of time to write it... but writing one as good and feature-rich as the popular ones would take huge amounts of effort.

would that type of database still be able to be created or used if Access were not referenced to in the project in some or Access being on the development machine?

Access is not needed at all - what you need is pre-installed with modern versions of Windows (95 onwards I think).

[szlamany]

In the 80's we created them in machine code - not on PC's at that time.

I'm working on one right now - kind of a rough prototype in VB.Net and will migrate that to C++ when we do the next pass.

[Nightwalker83]

In the 80's we created them in machine code - not on PC's at that time.

I'm working on one right now - kind of a rough prototype in VB.Net and will migrate that to C++ when we do the next pass.

Cool!

A .mdF is a different kind of database (SQL Server), and a .mdb is not actually an "Access" database (Access is just the best known program for using them).

I fixed up that small typo in post #3 I was actually referring to Access and not SQL.

Access is not needed at all - what you need is pre-installed with modern versions of Windows (95 onwards I think).

Someone once told me that if you are a developer or programmer you should not be even attempting to use Access in serious applications, although, it is a good tool to learn on there are better databases around.

[Maven]

Hi,

I have seen several thread on here saying that you can create a database in a programming language such as Java, C#, VB6, VB.Net without the use of references to built-in or third parties files such as Access, Oracle, etc. My point is that you can not and I have not seen any evidence suggesting otherwise. So that being said what languages are the programs such as Access, Oracle (other database back-ends) written in?

Thanks,


Nightwalker

You can manage the filesystem from most programming languages. Just read up on file processing.

But to answer your question, most will be written in C. Server programming is quite tedious because those types of systems get hit hard. Visual basic just wouldn't be up to snuff.

[Nightwalker83]

You can manage the filesystem from most programming languages. Just read up on file processing.

But to answer your question, most will be written in C. Server programming is quite tedious because those types of systems get hit hard. Visual basic just wouldn't be up to snuff.

Yes, I was under the impression they all needed to be written in the lower-level languages because of stuff like that but now I know that is not the case.

[Niya]

You can write a Database engine in any Turing Complete language. But in general, they are written in C/C++ most likely because of portability. SQL Server is most likely written in C with its tools like Management Studio written in a .Net language from 2005 onward. Oracle is probably written in C as well and I wouldn't be surprised if some of their admin tools for the raw engine was written in Java. My father wrote an ad-hoc Database engine in QuickBasic Extended back in the 90s that works perfectly to this day! There's really no best language for it though I'd say the best of them are written in C.

[dilettante]

I'm not sure how many people ever knew or remember that SQL was originally meant to be used by hand as an ad-hoc query language. You sat at a character-based terminal and typed in queries, and those returning rowsets displayed back a tabular result.

Early client/server use had the client acting as such a "terminal" sending to the database server and getting back and parsing tabular results. This was probably what eventually led to the common use of SQL as a programmatic query syntax today even though it wasn't designed for it at all.

The point being, SQL isn't a prerequisite for something to be a "database." But it has become so associated with relational DBMSs that anything non-relational is often labeled a "NoSQL" DBMS today.


It is also easy to forget that you don't always need a full DBMS, relational or otherwise. Sometimes simple random-access files fit the bill. Or bare ISAM files though these tend to be rare on PCs since Windows, VB, and .Net languages don't have any built in support. But there are tons of 3rd party libraries and tools if you hunt around. For historical reasons most of those tend to be tightly coupled to Cobol development tools and libraries on the PC, but they often expose APIs usable from other languages.

Microsoft's DOS Basic Professional Development System and VB-DOS which succeeded it had ISAM file support.

[NeedSomeAnswers]

Someone once told me that if you are a developer or programmer you should not be even attempting to use Access in serious applications, although, it is a good tool to learn on there are better databases around.

And they are correct, Access is not a database that you can seriously use for more then a few concurrent users, i could go into all the reasons but essentially the performance is too poor.

Its fine for small systems with low numbers of users or a learning aid, but as SQLExpress is free nowadays i would question why on earth you wouldn't use that instead.

[dilettante]

There are plenty of serious applications that have no multiuser requirements at all.

There is nothing called "SQLExpress" but there is a SQL Server Express. This also comes with lots of deployment pitfalls, just for starters collisions on database instances. It far from any kind of panacea.

[Niya]

This also comes with lots of deployment pitfalls, just for starters collisions on database instances. It far from any kind of panacea.

I don't agree. I never get any problems installing any version or edition of Sql Server. There are probably cases where you will get problems but this also stands true for any software. Usually has to do with corrupted Windows installations.

[techgnome]

It could also be argued that there is no such thing as an Access database... Access is actually just a front end to Jet and Ace based databases... there's a reason you can access them from VB (and other languages) w/o having to install Access... Unlike with SQL Server, it has to be installed... but Access is no more a database system than SQL Server Management Studio is one.

Not sure what kind of collisions you've run into but I've never had an issue with using SQL Server Express for deployment.

-tg

[dilettante]

If you try to install your application that uses an instance name of "addressbook" and some other application already used that name then BANG collision.

Instance names are global to the machine.

[techgnome]

That's not unique to SQL Server Express... that could happen with SQL Server... or MySQL or any service-run database engine. It also means I'm to frakin lazy to come up with something better than "AddressBook" ... alternatively if your target audience is savy enough, you could give them the option to determine what the database name is going to be. Or, you devise a method or dealing with the collisions... AddressBook01 ...

-tg

[Niya]

That's not unique to SQL Server Express... that could happen with SQL Server... or MySQL or any service-run database engine. It also means I'm to frakin lazy to come up with something better than "AddressBook" ... alternatively if your target audience is savy enough, you could give them the option to determine what the database name is going to be. Or, you devise a method or dealing with the collisions... AddressBook01 ...

-tg

I think dilettante is referring instance names not database names. No worthy database engine would allow you to create two databases with the same name. As for Sql Server instances....well I've never tested that. I never installed more than one instance of the same edition on the same PC but I've observed multiple default instances of different editions existing side by side. I haven't subjected this scenario to brutal testing but its possible that such a thing would cause problems.

[dilettante]

That's not unique to SQL Server Express... that could happen with SQL Server... or MySQL or any service-run database engine. It also means I'm to frakin lazy to come up with something better than "AddressBook" ... alternatively if your target audience is savy enough, you could give them the option to determine what the database name is going to be. Or, you devise a method or dealing with the collisions... AddressBook01 ...

-tg

I completely agree with all of this but the "lazy" part. You're hardly going to use GUIDs or something as instance names.

But it just goes to show that unless somebody is going to babysit it as "DBA" you have to be pretty cautious about using a C/S database for something like shrink-wrapped software.

Of course that's true to only a slightly lesser extent when using Jet MDBs requiring shared access among multiple machines. But as an embedded database meant for use only by your program on one machine it is hard to beat Jet for most routine tasks that need more than simple sequential and random files.


There is no single "best" answer because everything has its sore spots. However for almost every application people commonly ask questions about here ("here" meaning primarily desktop applications VB programmers ask questions about in these forums) Jet MBDs are plenty good enough.

Telling them they need to use some edition of SQL Server is just doing them a disservice unless there's some compelling reason why Jet isn't enough for what they're trying to accomplish.

[techgnome]

I completely agree with all of this but the "lazy" part. You're hardly going to use GUIDs or something as instance names.

Instance or database? I was thinking from a database stand point... instances... if there is an existing SQLServerExpress instance running, simply don't install it... it's not that difficult to find all existing SQL Server instances running, determine their version level and attach to the one you want. It takes a little know how but isn't impossible. Most installers should be able to check for a SQL Server installation... although it seems like half the population around here is always trying to re-invent the wheel and build their own installer, so who knows.

That said, my attitude about using a Jet database or ACE database is largely the same as if someone wants to use VB6... hey if it works for them, fine, what do I care? Right up until the moment they decide it needs to be multi-user... to me that's where it starts to fall apart.

Meanwhile on my personal pet projects, I never use Access/Jet/Ace... I find I don't like the front-end any more, it's clunky and as someone who (up until recently) had been using access since... well it was before there was an Access 95, that's for sure... Maybe Access 2.0 ??? what ever, the new interface is confusing and non-intuitive... meanwhile Ican create scripts far faster than I can usually create the table by hand, so it's more convenient for me to open SSMS, create a new database and go from there.

-tg

[FunkyDexter]

Saying SQL Server Express is prone to collisions on the naming of instances is a bit like Access (or Jet or Ace for the pedants among us ) is prone to collisions on the file path and name. Any entity on a computer that needs to be uniquely identified needs some sort of unique identifier. If you try and create a second entity with the same identifier it stands to reason you'll have a collision. Laying that as a failing at SQL Server's door is ridiculous.

Don't get me wrong, I still think there's a place in the world for Access (a pretty big place in fact) and I think us "serious" devs are often too disimssive of it as a tool. As a means for reasonably techy non-programmers to throw together some quick and dirty tools when Excel won't do anymore it's second to none. And the fact that it doesn't actually have to be installed while SQLServer express does is certainly a strength. But for any kind of business application that a developer is hoping to provide to a client I'd suggest that SQLServer (in some flavour or another) is almost always a better bet.

[szlamany]

If you look at the last 11 or so posts this thread went way off topic. Simple questions about the language of the backend of a database turning into a debate on early SQL syntax and how to name your instance. Strange group we have here...

[NeedSomeAnswers]

There are plenty of serious applications that have no multiuser requirements at all.

i would question whether you properly read my post !

This is what i said.

And they are correct, Access is not a database that you can seriously use for more then a few concurrent users

---

There is nothing called "SQLExpress" but there is a SQL Server Express.

Same difference, it was clear enough what i meant

and you could that out swap out MySQL, or if working with Web APPs and want an Object based DB, MongoDB and plenty of others.

There are just many many other alternatives to Jet/Access i would use first for any application.

If you look at the last 11 or so posts this thread went way off topic.

To many of the contributors have been spending to much time in ChitChat :0)

[Atheist]

I'd just like to add to the discussion that, if you are interested in the internal working of a database management system, take a look at the SQLite source code. It's really interesting to build the code and step through it in a debugger, to see how queries are handled.

[NeedSomeAnswers]

As a means for reasonably techy non-programmers to throw together some quick and dirty tools when Excel won't do anymore it's second to none.

I vehemently disagree with this, its the biggest problem i have with Access. A number of times early on in my career i worked at places were techy non-programmers knocked something up (that was built like crap) and i ended up having to fix/support them.

Access (in particular) seems to encourage the slightly techy people to make horrible solutions (normally using Access forms as well).

[szlamany]

I have seen these same disasters...

[FunkyDexter]

I vehemently disagree with this,

I used to feel exactly the same but over the years I've changed my mind. Unless your development department is so efficient or so well resourced that it can respond near instantly to every single changing business requirement that comes through the door (and I've never seen one that is) then the business is going to be left with two choices:-
1. Stop
2. Find a workaround

I've yet to come across a business that chose option 1 which means they are going to find a workaround. If they've got Access they'll likely develop a workaround in that. Take away Access and they'll develop a worse one in Excel. Take away Excel and they'll develop a really bad one on a roladex. But no matter how many layers you take away they WILL dvelop a workaround in something. You can fight that if you like, but you'll lose.

I think the mistake you can make as a Dev team is to try and support the workaround. Don't do that. It's a workaround, it's not a development. But looking at the workarounds that exist at a company is a great way of getting a to do list for future development with ready made prototypes. It's actually a great resource.

[NeedSomeAnswers]

I used to feel exactly the same but over the years I've changed my mind. Unless your development department is so efficient or so well resourced that it can respond near instantly to every single changing business requirement that comes through the door (and I've never seen one that is) then the business is going to be left with two choices:-
1. Stop
2. Find a workaround

I am still not convinced. In the places i worked earlier in my career essentially this happened -

the mistake you can make as a Dev team is to try and support the workaround

This was not a choice we had the business told us we had too. And this happened a number of times.

Excel i don't have a problem with as they cant really pass it off as development and try and get Dev to support it!

You can get Excel power users that know far more on Excel then any developer, so often you can just leave them to it.

I also don't have a problem with business using workarounds, its just when its access so often (specifically when they create an Access forms app) its gets seen as development as there is some code in there. Maybe it is down to the culture of the particular business you work for.

[techgnome]

I am still not convinced. In the places i worked earlier in my career essentially this happened -



This was not a choice we had the business told us we had too. And this happened a number of times.

Excel i don't have a problem with as they cant really pass it off as development and try and get Dev to support it!

You can get Excel power users that know far more on Excel then any developer, so often you can just leave them to it.

I also don't have a problem with business using workarounds, its just when its access so often (specifically when they create an Access forms app) its gets seen as development as there is some code in there. Maybe it is down to the culture of the particular business you work for.

That happens everywhere... any of us that's been doing this a while have been in that spot. It sucks. The difference is whether the company allows it to happen. Access/Excel power users are going to create thigns. Those things are going to proliferate... tht's a given. If the IT department is then string enough, it will (and should) say "No" when it comes to maintaining these tools. What happens next depends... at my current company, it stops. At my last one the "But, if you want us to maintain it, we'll take it in, rebuild it (properly) and then re-deploy it. But the original app tool, we won't touch." There our customer was the company internally anyways, not external clients. And that may play a role in what IT will or won't support.

-tg

[FunkyDexter]

This was not a choice we had the business told us we had too. And this happened a number of times.

Yeah, that can happen but I'd argue that's usually a symptom of a bad IT manager rather than the fault of a techy user for developing the work around. The IT manager needs the strength/negotiating skills to push back on stuff like that.

My last IT manager (a few years ago now) was really good at this but actually tool it one stage further. We wouldn't support the app that some techy user had built (well, maybe in an emergency) but he was happy for us to go out and help the techy user's skill themselves up. So we'd run simple sql courses, some database design stuff, excel power user courses, even some stuff on source control and so on. We wouldn't fix someone's workaround for them but we were happy to sit down and give them some pointers on how to fix it themselves. Essentially he didn't just accept that under the desk development would go on, he actively encouraged it! That might sound crazy at first but the effect was that the quality of the workarounds improved, they needed less support, and when they did need support it was more likely that a techy user couild meet that need without involving IT. It also meant that, because we were touching base with the guys that were working round our systems more frequently and more openly with no reprisals, we got a much better picture of what was actually out there. It was a very successful strategy.