Which RCS is the best James Blunt?
-
autocorrect misspelled postgres
snort.
Have i been living under a rock or something, cause until this thread, I'd never even heard of a "progress database."
www.progress.com
It's as powerful, roughly, as Oracle or MSSQL, but by default uses its own language instead of SQL. If you knew anyone in the US military in the last decade, who used the Defense Travel System for TDY, that was written in Progress (and I was involved in a tiny way with it.) It's fairly commonly used in the manufacturing industry (I know of at least 3 major MRP/ERPs that are or were written in Progress), and some use in the banking-related industry (IIRC Quicken uses it internally).
-
www.progress.com
It's as powerful, roughly, as Oracle or MSSQL, but by default uses its own language instead of SQL
All good, not criticizing anyone. It's just interesting the things you learn. I've just never encountered it. And I'm kinda grateful, cause the last thing i want at this stage of my career is to learn yet another platform specific DSL with a syntax that loosely resembles pascal.
Hell, just out of protest to all the other ruby devs I've ever worked with, i still insist on using braces instead of all that begin / end bullshit.
-
All editions of SQL Server since SQL Server 2000 wrap each unenclosed insert or update statement in an implicit transaction with the default isolation level.
OK, that's what I'd expect. Panic over. It was just Blakey being wrong.
-
I've just never encountered it.
That's what most people say. Of course, they don't market it to end users, anyway, mainly to companies looking to write software. So if you worked in a factory that used MFG/Pro for your MRP, you'd know you used that, and probably would have no reason as a user to know that Pro's written in Progress.
-
OK, that's what I'd expect. Panic over. It was just Blakey being wrong.
Yeah, seems everyone likes it when that's the case. But the problem with the 10G (which was previously 4G and before that 2G) limit is that it's enforced at a low level, which means that all the "best practices" database code in the world won't save you, cause even if you load the .mdf / .ldf into a full instance it is marked as "suspect" (which i always find amusing, because a far better word for it would be "fucked") and there isn't much that can be done to fix it.
-
No; it's me using the word "transaction" in the business logic sense (the only sense in which I've ever used it or heard it used professionally) and not some kind of technical wankery.
But sure, I'm wrong and stupid. Mega-dumb. Rock hard head here. Duuuh. Why not.
-
the scope is the for each statement
Because that's one statement. All the SQL engines that I know work the same way. Different syntax, but semantics recognisable at the transaction level.
-
This is true,
And lets not get started on that whole NoSQL "movement", or my utter hatred for MongoDB (which i can't distinguish from a memory mapped file containing json).
One thing I've always wanted to play with is Datomic. Whilst I don't have the political clout to get any of my clients to actually use it on a project, the principles seem kinda cool.
-
No; it's me using the word "transaction" in the business logic sense (the only sense in which I've ever used it or heard it used professionally) and not some kind of technical wankery.
While I have no control whatsoever over what you've heard or used professionally, I can assure you that transactions have a precise technical meaning when it comes to databases, and that they've had the same precise technical meaning for decades. All the textbooks and help webpages I've encountered on the topic in that time have had the same meaning (or been factually wrong). There are some nuances, but ultimately it comes down to defining a unit of work that either happens in its entirety (and typically durably) or not at all. This is obviously useful for implementing business processes that happen reliably.
Not all databases use transactions, but the ones that don't (usually NoSQL systems aimed at Big Data) aren't used to implement things that need to be done reliably. Anyone trying to do purchasing systems using MongoDB is
-
Because that's one statement. All the SQL engines that I know work the same way. Different syntax, but semantics recognisable at the transaction level.
Yes, but when you're writing code that way, you're not doing SQL. You can nest as many other statements as you want inside the first one, they're all part of the transaction. When you hit the end of the outermost scope, the transaction automatically commits. What I wrote was at least 4 separate statements, not including whatever might have been in the
....
-
One thing I've always wanted to play with is Datomic. Whilst I don't have the political clout to get any of my clients to actually use it on a project, the principles seem kinda cool.
That's an eventual-consistency model, isn't it? If your problem can work that way, I'm sure it will do nicely…
[… watches the video … skips … skips … watches …]
No, it's not. It relies on there being a total ordering of transactions (though it doesn't need transactions for reading). That would suck on a write-heavy workload, and would struggle to scale out. Also, it's schemaless and those have problems going fast with real-world data (as anyone who's tried to make an RDF database that is quicker than molasses in Svalbard will know full well).
I think I'll pass.
-
Yes, but when you're writing code that way, you're not doing SQL.
The one thing over SQL is that syntactic scoping of transactions. I thoroughly recommend it as an approach, and many languages' DB bindings have ways of implementing this feature.
-
Anyone trying to do
purchasing systemsanything at all using MongoDB isI really don't know what advantages this "database" possibly offers over memcached or redis in front of a real DB, although it somehow gained traction in the buzzword arena a few years back, so I keep finding these wildly inappropriate uses of it as a database, when it clearly isnt.
-
I really don't know what advantages this "database" possibly offers
It's web scale.
-
lol very funny... but seriously. Check out
Why You Should Never Use MongoDB
Disclaimer: I do not build database engines. I build web applications. I run 4-6 different projects every year, so I build a lot of web applications. I see apps with different requirements and diff…
I seriously don't know how you could not see the red-flags earlier, but... they missed them.
-
I've seen this cartoon before and while the script may be funny, the disturbing CGI characters and awful obviously text-to-speech voices completely ruin whatever joke might be there.
-
awful obviously text-to-speech voices completely ruin whatever joke might be there
I just think it sounds like an "anonymous" threat video... We are legion, we're a bunch of 14 y/o kids, we have a shitty DDOS tool, and we don't forgive, and we don't forget.... Oh and have an unusual obsession with Scientology.
-
it almost invariably corrupts your DB making it basically impossible to recover your data
I have done this several times for MSDB 2000 instances. I wouldn't call it easy but it was neither brain surgery. And 2005 express made it even easier.
I don't know what you butchered but upgrading express always just required plugging in the license.
-
I seriously don't know how you could not see the red-flags earlier,
You're assuming I didn't see them. I've been observing the problems with schemaless databases for at least a decade now; I've never been convinced that they were a great idea. Graph databases are better, as graphs do describe some types of problems well, but only if they have a schema. I have colleagues who still seem to be resistant to this idea.
Friends don't let friends use MongoDB.
-
I wouldn't call it easy but it was neither brain surgery.
No kidding... How?
I don't recall how it was with MSDE, but these days, you hit the limit and here's what you get.- Database stops accepting any new connections, and your client calls you because their app is broken.
- Open SSMS, database is suspect.
- Stop SQL Server service.
- Copy files to a location with access to a fully licensed version (doesn't matter if its standard, dev, enterprise, whatever)
- Load .mdf and .ldf (database is still suspect)
- a) Try any and all incantations of weird command line options google can find on blogs, stackoverflow, etc.
- b) Ask your Chinese speaking colleague to attempt the same thing using Baidu (cause sometimes that actually works)
- Use every commercial tool you can find to attempt to recover your data
- Run a few queries and realize that your data is still totally fucked and less useful than your most recent backup.
- Restore from the most recent backup and move on.
-
Uh non that sounds like the old pre-express way. With express 2005 and newer I just took a backup from the running system and restore on a different server for data cleaning. Then move it back. Naturally you have to watch the logs and maybe force that a bit but meh.
-
I just took a backup from the running system and restore on a different server for data cleaning
You can't backup a "suspect" database.
-
suspect
I was smart enough to not let it get as suspect I guess. But that has nothing to do with hitting the licence limit.
-
I've seen this cartoon before and while the script may be funny, the disturbing CGI characters and awful obviously text-to-speech voices completely ruin whatever joke might be there.
Actually, I think that was the joke. Anyone could make videos with...I've long forgotten who that was and they went out of business years ago...that, with a handful of scenes and characters, and by feeding it a script that it would produce machine-to-voice.
-
I think it's more likely that caffiend is full of shit, and/or the corruption he refers to is corruption of business data caused ultimately by failing to use transactions. (So part of the business transaction was committed and another part wasn't.)
Can't believe I missed that. This isn't that it "lost some data" or failed to complete a write transaction. It's that the fucking database instance doesn't work, won't let you connect to it, won't let you query it, won't let you back it up, basically it's useless.
My hunch was never that it had anything to do with the bit-length of whatever low-level disk access API the database engine uses, since this obviously isn't the case given that the full version has no problems.
For clarity, my suspicion is that that the line of code which enforces the limit is in some low-level part of the engine which grows the .mdf file. So despite doing everything right (from an application programming perspective) you roll a dice as to whether this transaction corrupts your DB, or just fails.
If the transaction fails, something tries again (whether automatic or meat-based), and we roll the dice once more. Keep doing this, and eventually it comes up 7, and everyone loses.
-
-
I want to use those chances at a casino
Oh great, another asshole who bets on "don't pass"
-
I highly doubt Microsoft would make that mistake.
You're giving me the impression that you think I think it is a mistake. I actually suspect that it is a deliberate sabotaging of the express edition so as to stop people from using it for real operational deployments. It's likely a really easy change to make; just zero out the high word of the offsets used in any call to
SetFilePointer(or otherwise restrict the range). Once the DB goes over 2GB, it becomes a ticking bomb, and the beauty of it is that it's a small change so that you don't have to debug vast amounts of other code. Evil, yet elegantly evil.Heck, even if this was something that was originally a bug, it is definitely in there now to support the commercial goals of Microsoft.
-
Wow. Conspiracy theories, I love them.
One slight problem. The size limit is 10 GB, not 2 GB.
-
10? That's deliberate then.
Probably imposed at the same point though.
-
10? That's deliberate then.
No shit.
I love how much an expert you are on the product you're talking about. Please preface all your posts in the future with, "disclaimer: I can't find my ass with both hands."
-
Of course it's deliberate. They're a software company, not a charity.
-
It's fairly commonly used in the manufacturing industry (I know of at least 3 major MRP/ERPs that are or were written in Progress), and some use in the banking-related industry (IIRC Quicken uses it internally).
Yeah. I remember a previous job where the ERP system was progress based.
-
No; it's me using the word "transaction" in the business logic sense (the only sense in which I've ever used it or heard it used professionally) and not some kind of technical wankery.
Can you please explain what you mean by "transaction in the business logic sense?" I've never encountered that particular phrase, and while I understand what a transaction is from an RDBMS POV, I don't know what business logic would have to say about that.
-
For example, if we have a new health insurance enrollment, that requires updating about 5-6 tables all at once. If any of the tables are updated without the others, the data is meaningless. So we open a transaction, do all the updates, and if any fail, roll-back all of them.
The business logic is something like, "it makes no sense for the user to have a new health application if they don't also have a health savings account application". To avoid the nonsensical data, we use transactions.
-
OK...so you're just making sure that all of the writes you need based on your business logic is within a single DB transaction.
Thank you for the explanation.
-
Yeah but this discussion makes me curious what other things people are using the word "transaction" to mean. When it comes to databases.
I mean sure, yes, every normal query has an "automatic transaction" but that's just to ensure an UPDATE doesn't end up half-UPDATEd. It's more like the journal in a filesystem than anything people would discuss in software development. (It's also implementation detail.)
-
Yeah but this discussion makes me curious what other things people are using the word "transaction" to mean. When it comes to databases.
What you're talking about is making sure that you stuff all of the necessary business logic into the appropriate window of the transaction, as defined by your RDBMS and whatever framework you're using.
For instance, I can think of several places in my application where I temporarily store stuff in a user's session and wait until it's all been properly generated / validated / whatever before I actually save it. And potentially, if I have an error in my code, the DB may throw it all back because of some problem (e.g., referential integrity).
What you're talking about is certainly important from an application point of view, but isn't very interesting, I think, when we're talking about RDBMSes, unless they have no transaction capability at all. The business logic is at a different level.
-
Well, our entire product is based around a REST API, so a "transaction" at the level you're talking about consists of like 50 REST calls over a period of an hour or whatever. Except we don't really "transact", because we're not e-commerce.
Generally speaking, we use "transaction" to refer to the database work that goes on during a REST API call. If someone said "transaction" and meant something else, I'd be confused until I figured out what they were talking about.
-
Well, our entire product is based around a REST API, so a "transaction" at the level you're talking about consists of like 50 REST calls over a period of an hour or whatever. Except we don't really "transact", because we're not e-commerce.
Yeah...that's weird. My stuff isn't e-commerce either. Closer to ERP, but not actually manufacturing.
Generally speaking, we use "transaction" to refer to the database work that goes on during a REST API call. If someone said "transaction" and meant something else, I'd be confused until I figured out what they were talking about.
That was the disconnect I had when reading what you said. So...I guess you don't really have the concept of a user session? In my case, I was thinking of where a user might have to do multiple steps, across multiple pages, before they have something worth saving.
I have some places in my application where we have a REST API, but there again I have a user session where I could keep track of stuff across multiple REST calls. It so happens that the few places I have a REST call do anything, each time the browser talks to the server, it's wrapped in a single transaction. But again, that's all at a different level than the transaction handling of the framework (JBoss / Seam / Hibernate / Oracle) and my code deciding what to do.
-
So...I guess you don't really have the concept of a user session?
We do, but only for authentication.
The REST API doesn't ever store anything in the Session. One of the ways we keep the product scalable.
EDIT: think about, say, TurboTax. It could take hours and hours to finish a "transaction" in our system, long enough that any normal Session would time-out. So we can't store pending stuff in the Session anyway, or we'd be looking at really angry users who "lost" all their selections because the Session timed-out.
-
who that was
I watched a bit of the video, and it's watermarked for Xtra Normal. A lot of people used that, what, 8-9 years ago?
-
I remember a previous job where the ERP system was progress based.
You remember which one? At various client sites I've worked with MFG/Pro, Symix/Syteline, Trend, and, a loooong time ago, WDS-II.
-
So we open a transaction, do all the updates, and if any fail, roll-back all of them.
I would call "all the updates" something like sub- or nested transactions, if I needed to call them out, but that's from a RDBMS point of view. In Progress, you can explicitly define a nested transaction and, if necessary, roll it back without rolling back the outer one.
-
Why?
Seriously. What's in it for me? What's my incentive?
Well, probably a lot depending on who you work for. If you were able to contribute in a way that brought benefit to your employer who was using said OSS technology, you'd probably be on a significantly higher 6 figure salary.
In large scale deployments, depending on the business model MSSQL and Oracle can be prohibitively expensive, especially if you rely on high volumes and low margins per user.
This is not the case in the industry I work in, which is basically an end-to-end Oracle shop, with a few supporting apps deployed on MS SQL Server. But there are plenty of viable companies which couldn't sustain the licensing costs of an enterprise scale deployment of a commercial RDBMS.
And just an FYI, a friend of mine bills roughly $2K per day as a pgsql consultant, and he's worth every penny.
-
I really don't know what advantages this "database" possibly offers over memcached or redis in front of a real DB,
Write intensive workloads over a horizontal partitioned database
-
And subject to the restriction that losing a particular write is Not A Big Deal. So nothing with money involved.
-
You remember which one? At various client sites I've worked with MFG/Pro, Symix/Syteline, Trend, and, a loooong time ago, WDS-II.
Ah, I believe it was Trend. I couldn't have remembered that, but it's familiar now that I see it.
-
Well, probably a lot depending on who you work for. If you were able to contribute in a way that brought benefit to your employer who was using said OSS technology, you'd probably be on a significantly higher 6 figure salary.
Hahaha. We have to follow HIPAA. We don't even use open source shit, generally. (I guess WebAPI, but it was made open source only after we adopted it.)
Adding open source shared libraries to our product would get me fired, not promoted.
-
Hahaha. We have to follow HIPAA. We don't even use open source shit, generally. (I guess WebAPI, but it was made open source only after we adopted it.)
Adding open source shared libraries to our product would get me fired, not promoted.
Is there an actual regulation or whatever that requires that sort of reaction? Or just employer paranoia / ossification?
