Win a copy of React Cookbook: Recipes for Mastering the React Framework this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

SQL Server 7.0 & IDENT_CURRENT

 
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

SQL Server (or sqlserver for lazy searchers) 7.0 doesn't support IDENT_CURRENT which is used througout the forum code. Therefore, if you are planning to use SQL Server 7.0 with JForum, get ready for a bad surprise :?

I couldn't find any alternative to this in Sqlserver 7.0, and I guess @@IDENTITY cannot be used since it does not accept a table parameter.

Therefore I had to switch to SQL Server 2000, which seems to work fine so far...
[originally posted on jforum.net by cagin]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, I'm not surprised to hear this -- especially with SQLServer 7.0. I like 2000 much better, but prefer non-MS whenever possible. :-)

In any case, such SQL statements are OFTEN PROBLEMATIC across different DB platforms. This is where a mature DB encapsulation layer would pay off in droves (e.g., Hibernate).

One of these days I might just start re-writing the entire DB abstraction layer so it can use something like this. Oh, if I only had the time -- 99% of our DB issues would be resolved. :-)
[originally posted on jforum.net by fcgreg]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might still get problems as some DBs would then not be supported by the "DB Abstraction Layer", but at least then you can place the blame onto others .

Also, in order to do that you might need to add other things to the DB, like defined foreign keys, which in some cases could create problems (meaning more work changing the software).

On a side note, I started developing some forum software based around hibernate and even though I had to stop due to more critical projects popping up, I was already able to post, edit messages, create forums... both in HSQLDB and Oracle, using Clobs. The only problem was defining the DB creation scripts, even though one might try to let Hibernate create the tables for you (I have not tested it). I have not tried with other DBs though, so I'm not sure how "far" the multi-DB support goes.


[originally posted on jforum.net by GreenEyed]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

GreenEyed wrote:You might still get problems as some DBs would then not be supported by the "DB Abstraction Layer", but at least then you can place the blame onto others .

Also, in order to do that you might need to add other things to the DB, like defined foreign keys, which in some cases could create problems (meaning more work changing the software).

... The only problem was defining the DB creation scripts, even though one might try to let Hibernate create the tables for you (I have not tested it). I have not tried with other DBs though, so I'm not sure how "far" the multi-DB support goes.


Well, they already go VERY FAR. With hundreds of active developers, testers and project contributors, it is generally best to let them do what they know best and take advantage of their work. Why re-invent the wheel any further at this point?

For example, take a look at the list of supported databases for Hibernate:

Official supported by the team

Supported by the community (includes several more)

There are other systems as well, like Apache's OJB.

Just my two cents. I fully hope to be more actively assisting the project towards these goals in the near future -- if I can only squeeze in the time. We'll see.

Apologies to Cagin for slightly hijacking his OT.
[originally posted on jforum.net by fcgreg]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eummm,

Don't get me wrong, I'm not saying it does not work or that I believe support is weak. I was just saying I had not tested it personally, so I'm not going to assert anything. I do use Hibernate and other ORM layers but I have just tested them with Oracle and HSQLDB, and that's why I won't personally go farther than that. One thing is documentation and theory and another thing is real world and what it works.
I was just saying that one needs to be careful.

For example, on the lists you provided there is no support for SQL Server 7.0, either official or community, just for SQL Server 2000. And with lots of comments about unsupported features due to JDBC driver implementation problems. And that's something you have to take into account.

I was just saying, it's not that easy. Nothing more, nothing less.
[originally posted on jforum.net by GreenEyed]
 
Did you just should on me? You should read this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic