Now I'm Confused - Php/MySQL

[EthicalDesign]

Hi Guys,

I wonder if anyone can give me a push in the right direction to figure this out.

I have a MYSQL query:

DELETE FROM Subcribers WHERE SubscriberID='14a269d7c10ff9d6aed3a07e256555f3';

This works fine when I log into MySQL directly through SSH (as root).

In my php script:

mysql_query("DELETE FROM Subcribers WHERE SubscriberID='14a269d7c10ff9d6aed3a07e256555f3';");

Doesn't work. No errors are produced. Just doesn't delete the record (which exists).

This is just on my dev box (running fedora) and I'm connecting to MySQL as the root user. All of the other queries work fine except this one.

I've checked the privileges using phpMyAdmin and all seems to be OK.

Anyone got any ideas why this might be happening? I've tried web searches for it but can't seem to find exactly what I'm looking for.

Any pointers would be much appreciated.

P.S. I know both of these codes are the same, so it isn't a case that I've deleted the record already with MySQL and that's why the delete isn't working. I just use them as an example to illustrate that both queries are exactly the same, one works, one doesn't.

[EthicalDesign]

Nevermind. Figured it out. I won't mention what the problem was because I'm too embarassed :rofl:

[Kwak]

If you share, newbies can learn from your mistake.

[projo]

the semicolon

[EthicalDesign]

LOL! No it was a typo in the original code. I dropped a letter somewhere (can't remember exactly which one now because it was a while ago).

If there's anything newbies can learn from this, its if you've been working on the same piece of code for a while and something doesn't work that you can't explain (but without any error messages), go and take a break from it otherwise you'll re-read and re-read the same piece of code looking for the mistake and your mind will auto-correct it as you read it making it harder to spot. That's what was happening in this case anyway.

After taking a break for a bit, I came back and looked at it and it spotted it immediately. Doesn't often happen to me, but I guess I was tired or something.

[CodeSheepy]

Hello,

You should try to use proper formatting, it helps the learning process:

DELETE FROM `Subcribers` WHERE `SubscriberID`= '14a269d7c10ff9d6aed3a07e256555f3';

See the ` marks? You should add them, if I'm not mistaken the new specification of PHP and MySQL requires them. Just a little tip ;)

[EthicalDesign]

Thanks CodeSleepy. This is the first I've heard about that.

You wouldn't happen to have a link to an article/document about this would you?

I can't seem to find anything about it in the myssql online manual (though there are a few code snippets that users have submitted featuring this I thought this was a preference rather than a requirement.

I'm already using a database abstraction layer, so it should be fairly easy to change if I need to, but I'm not sure what impact this would have on code portability to postgre and MSSQL as presumably they expect the old style queries (if you know anything about that any pointers would be welcome).

Thanks again!

[CodeSheepy]

Originally posted by EthicalDesign:

Thanks CodeSleepy. This is the first I've heard about that.

You wouldn't happen to have a link to an article/document about this would you?

I can't seem to find anything about it in the myssql online manual (though there are a few code snippets that users have submitted featuring this I thought this was a preference rather than a requirement.

I'm already using a database abstraction layer, so it should be fairly easy to change if I need to, but I'm not sure what impact this would have on code portability to postgre and MSSQL as presumably they expect the old style queries (if you know anything about that any pointers would be welcome).

Thanks again!

I'm telling you this off my experience :) I've found that quite a few MySQL statements don't work if not properly formatted. Check out devshed, php.net and mysql.com. I think they're great resources.

[EthicalDesign]

The problem with the query above wasn't because it was incorrectly formatted, but because I made a typo in the original code.

I've done a bit of searching but can't find anything relating to this being required for new versions of mySQL/php yet. If it is a new requirement then it'll be documented somewhere, just can't seem to find it yet (there's so much mysql info out there it's taking forever to wade through it all to find what I'm looking for).

Does anyone else have any links or information about this?

[CodeSheepy]

Maybe its just me then :) But I've found insert statements don't work right if the formatting isn't there. Perhaps it's something to do with our mysql configuration or php configuration.

But I'm telling you as an experienced programmer of over 10 years that its always proper to follow full formatting rules that a language puts forth. They're there for a reason ;)

[Cow]

EthicalDesign,

It is not necessarily a requirement perse. However, correct formatting and syntax are important. While you can get away with a lot of shortcuts, some just aren't worth taking in the long run.

:)

[EthicalDesign]

Thanks cow.

I understand the importance of correct formatting and syntax (I'm not a newbie despite the stupid typo I made - but that happens to the best of them particularly at the end of a long shift).

My sql statement is correctly formatted, according to the mySQL manual itself. Nowhere in the MYSQL manual does it enclose field and table names in single quotes in their own examples, and the vast majority of code snippets that other programmers have submitted don't use these either. Neither do the vast majority of the open source or commercially available scripts that I've come across so far (as far as I know).

Up until today I've always assumed single quotes are merely used as delimiters for SQL strings.

I've been using SQL in various RDBMS for over 10 years and this is the first I've heard about enclosing table and field names in single quotes (though I've seen the odd piece of code where this is the case I've always assumed this was just a personal excentricity/preference or even mistake of the programmer).

If this is something new to mysql and php coding standards I'll need to investigate how that is going to work with other databases that use SQL such as Oracle (which I haven't used for years),Postgre, MSSQL otherwise field names will also need to be abstracted along with the database and table names/prefixes to make my scripts fully portable.

If I can't find any definite documentation about this then I'll need to assume (for the moment) that this is just a rumour.

No offence to Codesleepy because I know you were just offering me a tip (and if it turns out to be true then I'll be incredibly grateful for that), but unless I can find something official that documents this I don't want to start changing my coding practices.

[EthicalDesign]

Originally posted by CodeSheepy:

But I'm telling you as an experienced programmer of over 10 years that its always proper to follow full formatting rules that a language puts forth. They're there for a reason ;)

My problem is that I can't find anything that specifies this is a rule in the first place.

It's not that I mean to challenge your own programming skills, just that I need to carefully check things like this out. I've been programming myself in various languages for a bit over 10 years myself, so I understand the importance of following syntax/formatting rules.

I just can't find any rules about this documented anywhere so far.

Not saying you're wrong. You could well be right and I just haven't came across this yet. I really need to find some documentation about this to read if it is something new that I don't yet know about though.

[CodeSheepy]

Originally posted by EthicalDesign:

Thanks cow.

I understand the importance of correct formatting and syntax (I'm not a newbie despite the stupid typo I made - but that happens to the best of them particularly at the end of a long shift).

My sql statement is correctly formatted, according to the mySQL manual itself. Nowhere in the MYSQL manual does it enclose field and table names in single quotes in their own examples, and the vast majority of code snippets that other programmers have submitted don't use these either. Neither do the vast majority of the open source or commercially available scripts that I've come across so far (as far as I know).

Up until today I've always assumed single quotes are merely used as delimiters for SQL strings.

I've been using SQL in various RDBMS for over 10 years and this is the first I've heard about enclosing table and field names in single quotes (though I've seen the odd piece of code where this is the case I've always assumed this was just a personal excentricity/preference or even mistake of the programmer).

If this is something new to mysql and php coding standards I'll need to investigate how that is going to work with other databases that use SQL such as Oracle (which I haven't used for years),Postgre, MSSQL otherwise field names will also need to be abstracted along with the database and table names/prefixes to make my scripts fully portable.

If I can't find any definite documentation about this then I'll need to assume (for the moment) that this is just a rumour.

No offence to Codesleepy because I know you were just offering me a tip (and if it turns out to be true then I'll be incredibly grateful for that), but unless I can find something official that documents this I don't want to start changing my coding practices.


This is not a new practice :) Look at PHPMyAdmin, now that's a well coded PHP script, even that uses the ` notations for SQL statements. The prime quote notation has been there since MySQL was made.

Formatting is made to make code more legible. Perhaps I am this way because I'm a hardcore coder, LOL, most programmers start drooling when they see my coding samples (because of the extensive commenting, tabulation). I suppose everyone programs in their own way :)

No offense taken by the way.

[CodeSheepy]

Originally posted by EthicalDesign:

My problem is that I can't find anything that specifies this is a rule in the first place.

It's not that I mean to challenge your own programming skills, just that I need to carefully check things like this out. I've been programming myself in various languages for a bit over 10 years myself, so I understand the importance of following syntax/formatting rules.

I just can't find any rules about this documented anywhere so far.

Not saying you're wrong. You could well be right and I just haven't came across this yet. I really need to find some documentation about this to read if it is something new that I don't yet know about though.

I haven't found this online to be honest. I came across this after we started programming work on our backend's new version. Again like I said previously maybe its our php / mysql configuration.

While I was coding a relatively simple routine for the life of me I couldnt figure out why the heck the sql statement wouldn't execute properly. After some hair pulling i 'formatted' the SQL statement and bam it executed :)

Normally an experienced programmer would be ashamed to discover that it was a silly little mistake causing code not to execute but then we must all realise that we are only human and make mistakes (it's human nature).

[EthicalDesign]

Originally posted by CodeSheepy:

This is not a new practice :) Look at PHPMyAdmin, now that's a well coded PHP script, even that uses the ` notations for SQL statements. The prime quote notation has been there since MySQL was made.

Sorry. I assumed it was something new because you said that it was required in the new versions of mysql/php.

I can't find any reference to this in the official mysql documentation though.

Just had a look at some of the phpmyadmin code and you're right it is used in there.


Formatting is made to make code more legible. Perhaps I am this way because I'm a hardcore coder, LOL, most programmers start drooling when they see my coding samples (because of the extensive commenting, tabulation). I suppose everyone programs in their own way :)


But adding single quotes doesn't really do anything in terms of code readability to my eyes. If anything it makes it worse imho. SQL queries are already very readable without this.

If this is considered a best practice rather than just a personal preference then I really need to learn more about it.

There doesn't appear to be any reason why this is required though as any code that doesn't follow this practice is still going to work as far as I can see so far.

[EthicalDesign]

Originally posted by CodeSheepy:

I haven't found this online to be honest. I came across this after we started programming work on our backend's new version. Again like I said previously maybe its our php / mysql configuration.

:eek: So your SQL queries don't work if you don't enclose your table and field names like this?

This suggests that it isn't merely a code formatting preference for readability but a functional requirement. What version of php/mysql were you using?


While I was coding a relatively simple routine for the life of me I couldnt figure out why the heck the sql statement wouldn't execute properly. After some hair pulling i 'formatted' the SQL statement and bam it executed :)


Are you sure you didn't correct a typo or something at the same time? This is the first time that I've heard about this being required. The MySQL manual itself doesn't even seem to mention anything about this.

Do you know how queries like this (with the quotes around the field/table names) would execute in other SQL Compliant DBs?


Normally an experienced programmer would be ashamed to discover that it was a silly little mistake causing code not to execute but then we must all realise that we are only human and make mistakes (it's human nature).

I know the feeling :rofl:

[CodeSheepy]

Not all my sql queries, certain ones :) I think insert is one of them.

---
Are you sure you didn't correct a typo or something at the same time? This is the first time that I've heard about this being required. The MySQL manual itself doesn't even seem to mention anything about this.
---
Nope I didn't correct any typos.


---
I know the feeling
---
Most good programmers do ;)

[Cow]

Hmm .. it appears he has disappeared. So, I'll answer your question. We're using PHP 4.3.6.6 and MySQL 4.0.18. Although I feel this is irrelevant to the conversation. Oh by the way, it MIGHT be an NT issue .. we program on Windoze platforms a lot.

But there you go :D

[EthicalDesign]

Originally posted by CodeSheepy:

Not all my sql queries, certain ones :) I think insert is one of them.


Thanks. I'll look into that. Can you remember what version of mysql/php you were using?

btw: just realised that your username is CodeSheepy not CodeSleepy. Sorry 'bout that - I've been reading/responding the this thread quickly while doing other things.

[EthicalDesign]

Originally posted by Cow:

Hmm .. it appears he has disappeared. So, I'll answer your question. We're using PHP 4.3.6.6 and MySQL 4.0.18. Although I feel this is irrelevant to the conversation. Oh by the way, it MIGHT be an NT issue .. we program on Windoze platforms a lot.

But there you go :D

Ah..Thanks cow. You beat me to it.

I thought it might be relevant because I haven't come across this problem myself so far (even with fairly complex sql queries on a number of SQL compliant DBs) and Codesheepy mentioned it might be something to do with those versions.

You wouldn't happen to know what the original insert statement was would you so I can give this a whirl (I appreciate this is probably asking too much but I need to keep ontop of things like this - if it does turn out to be a requirement for a particular SQL database or even a bug or peculiarity of php for windows it'll be helpful if I can play around with this and adjust my scripts accordingly).

Do you know how other SQL Compliant DBs like Oracle,Postgre and MS SQL will handle the quote enclosed table and field names? I really need to work that out before I start adopting this practice myself as I want my scripts to be compliant with other unix/linux DBs rather than coding to accomodate a peculiarity of php/mysql for windows (if that turns out to be the case).

[CodeSheepy]

Hello,

While I don't have the original SQL code on me any longer, here's a sample insert statement from our current coding, all our insert statements look like this:

"INSERT INTO `racks` ( `UID` , `Name` , `Location` , `Type` , `AssignedTo`, `Full` ) VALUES ('', '$sName', '$sLocation', '$sType', '$sAssignedTo', '$sFull');

While I personally dont have onhand experience with too many other SQL languages but it is safe to say that any SQL code can be adopted for another SQL platform. My focus is pretty much MySQL as I love the speed and flexibility it offers! :)

Happy Coding! :D

[EthicalDesign]

The most probable reason why your original queries weren't working without the quotes is because you were using a reserved word for your field names.

I'm not sure about the original statement but in the above you're using 'Type' which is a mysql reserved word for table creation. Don't know if it would cause a problem with that specific query, but it's a big no no to be using any reserved words for table/fieldnames.

I've asked around a few places and as far as I can gather, this isn't a required practice unless you want to use a reserved word, or non-alphanumeric characters for a field/table name (which isn't usually the case because everyone knows to avoid them).

On the plus side your code should be more future proof because it'll account for any new reserved words in the future.

I can't see this being a problem for my own code because I avoid reserved words like the plague already and most of my table/field names are very unlikely to become reserved words in the future (I often prefix with FLD or TBL which is an old trick to avoid reserved words).

It might still be worth me doing things this way and updating some of my old scripts just to be on the extra safe side though.

Just not sure if I can code like this and know for sure if it'll work with other DBs, or if I should be abstracting field names aswell as table names to allow this to be easily changed.

Anyone else know if enclosing field and table names like this will work with all SQL compliant dbs (oracle,Postgre and MS being the most important ones to me at least)?

[CodeSheepy]

Originally posted by EthicalDesign:

The most probable reason why your original queries weren't working without the quotes is because you were using a reserved word for your field names.

I'm not sure about the original statement but in the above you're using 'Type' which is a mysql reserved word for table creation. Don't know if it would cause a problem with that specific query, but it's a big no no to be using any reserved words for table/fieldnames.

I've asked around a few places and as far as I can gather, this isn't a required practice unless you want to use a reserved word, or non-alphanumeric characters for a field/table name (which isn't usually the case because everyone knows to avoid them).

On the plus side your code should be more future proof because it'll account for any new reserved words in the future.

I can't see this being a problem for my own code because I avoid reserved words like the plague already and most of my table/field names are very unlikely to become reserved words in the future (I often prefix with FLD or TBL which is an old trick to avoid reserved words).

It might still be worth me doing things this way and updating some of my old scripts just to be on the extra safe side though.

Just not sure if I can code like this and know for sure if it'll work with other DBs, or if I should be abstracting field names aswell as table names to allow this to be easily changed.

Anyone else know if enclosing field and table names like this will work with all SQL compliant dbs (oracle,Postgre and MS being the most important ones to me at least)?


I'm aware of the type issue, but the original sql query did not have any reserved words in it :) Anyways, this is why I find it good to adopt all coding practices because it leaves no margin for error :)

Furthermore, I never use reserved Keywords in table names, the database this is being used on is a port of an older database which wasn't exactly programmed by me but the structure had to be carried forward for the sake of the database itself.

I hope that helps you ;) Thats all from me on this thread as I gotta get back to work (yay more coding :rolleyes: )

[EthicalDesign]

"INSERT INTO `racks` ( `UID` , `Name` , `Location` , `Type` , `AssignedTo`, `Full` ) VALUES ('', '$sName', '$sLocation', '$sType', '$sAssignedTo', '$sFull');

Is UID an auto increment field? If so why are you using '' in the insert statement?

I've never needed to do this myself, so was just wondering if there's a reason behind your approach with this, particularly after being turned onto this field/table quoting thing as a means to futureproof against new reserved words.

Might be something else I can pick up from you guys :)

[EthicalDesign]

Originally posted by CodeSheepy:

I'm aware of the type issue, but the original sql query did not have any reserved words in it :)

Ah well. There's that theory out of the window. I can't for the life of me think what was wrong with your original code in that case.

Anyone else have any ideas?

This isn't a documented requirement or coding practice (outside of using reserved words or non alphanumeric characters) in any documents I can find so far so I'm still a bit baffled about why a query would fail like this.

Perhaps it is just a peculiarity of those particular versions on the windows platform afterall.


I hope that helps you ;) Thats all from me on this thread as I gotta get back to work (yay more coding :rolleyes: )

It was really helpful thanks :)

I don't think this will be an issue with my own code but it definitely seems like a good idea for future proofing so thanks for the heads up.

I'll probably start using this technique myself for that reason alone even if all my code does work as it is.

Just got to work out whether I need to go to the trouble of abstracting my field names or if I can rely on other SQL dbs to properly handle the quoted table/field names.

Anyone using Postgre, oracle and MS SQL that could run a few queries for me to test it out?

Thanks.

[EthicalDesign]

Just a quick heads up for you guys about the other DBs. I'm not sure about Postgre and Oracle yet, but I'm told that MSSQL splutters at enclosing field names in back quote characters (from an experienced DBA who is doing mySQL certification and is running an MSSQL database aswell).

Apparently this method can be used in MSSQL but not with the back quote character (only single quotes,double quotes or angle brackets)

I haven't had a chance to try this out for myself yet because I want to find out about oracle and Postgre before I start experimenting, but if this is the case (it would seem that way) it means that the code you're writing isn't going to be portable to MSSQL at least (as MSSQL makes such a big deal about SQL compliance it could be that this is a bad practice in terms of portability to other DBs aswell).

A possible reason this is used extensively in the phpMyAdmin scripts could be because phpMyAdmin was written specifically for managing MySQL so doesn't need that portability.

That might be something that you want to look into.

[Cow]

Noted. However, I will say this before leaving the subject alone. Microsoft is lucky we're even using their OS as a development platform for a lot of our virtual applications. We're not total fans of MSSQL although we can adopt to it fairly easily. It kind of scares us when Microsoft gets into other fields they shouldn't be dabbling in.

Again, that is my personal perspective. I'm not KNOCKING Microsoft for trying, I'm just saying it very worriesome when they start developing database engines.

[EthicalDesign]

Microsoft aren't just getting into developing relational database systems, they've been doing it for years. Don't get me wrong - I love mySQL but there are some great features that Microsofts SQL offers that you won't find in mySQL yet (precompiled stored procedures for example).

MSSQL server has a very long history (it was developed ontop of earlier rdbms by Ashton Tate called sybase if I remember correctly). They went into partnership with Ashton Tate in the mid to late 80's and have been involved in its development since then (at that point the product that formed the platform for MSSQL version 1 had already been in development/use for a number of years).

This mighn't just be a case of only Microsofts SQL server not accepting these back quotes but it could be something that other SQL compliant DBs are going to fall over aswell.

It could well turn out to be a bad programming practice due to it's specificity to mySQL, resulting in scripts that will only work with mySQL backends and no other databases.

I'm going to try to find out how postgre and oracle handle these quote characters for my own future reference so I'll post here to let you know how I get on.

I'd like to get to the bottom of this because it looks like a great way of being 100% certain that your database is futureproofed, but only if it can be done in such a way that it doesn't effect portability.

[Cow]

While I am aware of MSSQL's history and there are some great features, I'm still a bit biased towards open-source. Hey, call me a fool or whatever! hahah .. :)

I've found MySQL to be marginally faster than MSSQL but then again, thats like saying try to notice the difference between 2.4ghz and 2.67ghz. You know what I mean?

[EthicalDesign]

OK. So far I have:

In MySQL it's ``
In MSSQL it's []
In PostgreSQL it's "" (double quotes)

Not sure about Oracle yet, but it wouldn't surprise me if they're using something specific to them aswell.

This really isn't a good programming practice unless you're abstracting both field and table names, with an easy adjustment to account for differing backends (and that in itself would likely cause a slight performance hit). It doesn't look like you're using any abstraction from the query you posted above though :eek:

If it were just a case of reserved words being used then a simple solution that would avoid all of this would be to prefix your table/field names with TBL and FLD respectively, but that didn't appear to be your problem from what you are saying.

I can't really work out what the problem would be if no reserved words were being used and your query still didn't work.

I'm going to have a serious think about abstracting my field names myself. You guys should consider this if you're adopting this approach as a best practice because it seems that it would seriously limit the portability of your scripts.

[Cow]

Welll, once we start porting our software for commercial use, we'll look into some portability options. I'm not sure if Asher (CodeSheepy) and I exactly agree as to how proprietary we should make our software. We're currently working on a few intranet solutions and I think it'd be best if we made the intranet totally dependant on our company. This in itself, though, can have a very negative side in case we just want to sell off the licenses and retire in some carribean beach somewhere ;)

Lots to consider ...

[EthicalDesign]

Originally posted by Cow:

While I am aware of MSSQL's history and there are some great features, I'm still a bit biased towards open-source. Hey, call me a fool or whatever! hahah .. :)

Sorry. Must have misread you. It seemed that you were saying they were just getting into dabbling with database engines.

I know what you mean about opensource. I'm moving more in that direction myself (as soon as they start releasing photoshop and illustrator for linix I'll probably drop it for the desktop aswell).

MS SQL server is a good database though. You have to give them that. Even windows I've found to be pretty good - I just prefer the structure of linux as it seems to make more sense to me.

I've found MySQL to be marginally faster than MSSQL but then again, thats like saying try to notice the difference between 2.4ghz and 2.67ghz. You know what I mean?

I've found the opposite myself (at least when comparing it to a well constructed MSSQL system). MSSQL seems to have the edge in speed from what I can tell. It may be that you're comparing it to a database that doesn't take advantages of the more advanced features (like stored procedures) that MSSQL offers.

I'm sure this is down to all sorts of configuration options though so it's probably hard to tell exactly.

Either way, I'm quite happy using mysql as an alternative even if it did turn out to be a bit slower because its a great db and I love the opensource philosophy.

[monaghan]

MSSQL 4.2 was essentially Sybase with a MS hat on (running on MS OS/2 if I remember correctly), 6.0 & 6.5 were essentially NT versions of the Sybase product. 7.0 & later are completely different animals :)

Not sure about the Ashton Tate & Sybase link though. Microsoft did buy FoxPro which was essentially the Ashton Tate dBase product in a Windows wrapper.

I can't wait for views & SP's in MySQL, it'd make my life much easier :)

Future proofing is a good idea, but usually a new version will introduce new or better features, so I guess you'd want to give your app a review anyway.

[EthicalDesign]

Originally posted by Cow:

Welll, once we start porting our software for commercial use, we'll look into some portability options. I'm not sure if Asher (CodeSheepy) and I exactly agree as to how proprietary we should make our software. We're currently working on a few intranet solutions and I think it'd be best if we made the intranet totally dependant on our company.


If that's the case, perhaps you should write your own db and use ' « ' and ' » ' for delimiting illegal fields then you'll be up there with the best of them :rofl:

Why they all can't just use the same bloody character escapes me. I'd have thought something like this would have been determined by some standard body somewhere :(

[Cow]

EthicalDesign,

No, I'm sorry if I wasn't clear in my statements. I've literally taken an hour's nap from the computer this morning. We have to get this project done in a week and there just aren't enough hours in the day. :(

As far as speed goes, this again all depends on your structure. We've found it very easy to manipulate MySQL to make it go faster, but when trying to port some of our code to MSSQL, we got the opposite effect. This may be due to several factors, though. I'd be interested to go in depth on your and our programming techniques so we can perhaps find a middleground in the sense that everyone's techniques differ and perhaps we could find a median that is sufficient for most programmers.

Monaghan, you have a point about foolproofing. Although if you can perfect your code for maximum portability, then I'm sure implementing new streamlined database features should be even easier. This is assuming that you provide yourself with sufficient commenting and code tabulation. You have no idea how many projects we get with no commenting. It's worse than programming from scratch.

[EthicalDesign]

Originally posted by monaghan:

Not sure about the Ashton Tate & Sybase link though. Microsoft did buy FoxPro which was essentially the Ashton Tate dBase product in a Windows wrapper.


I think Ashton tate owned the rights or marketing rights to sybase or something so it was them that microsoft went into partnership with. I could be wrong but I think first version of MSSQL server were a joint thing between microsoft and Ashton Tate.

Anyway..time to quickly change the subject because I'm starting to show what a geek I am (not to mention how long in the tooth I'm getting).

[Cow]

Originally posted by EthicalDesign:
(not to mention how long in the tooth I'm getting).

And with that said, I think I'm going to go to sleep for a few minutes. I just corrected a crapload of errors in my previous post. Not a good sign. This just means I need to close Notepad and Fireworks and pop a headache reliever or something. :baghead:

I'm interested to see what you come up with, though. I'll follow up on this thread when I wake up ...

[EthicalDesign]

Originally posted by Cow:
As far as speed goes, this again all depends on your structure. We've found it very easy to manipulate MySQL to make it go faster, but when trying to port some of our code to MSSQL, we got the opposite effect. This may be due to several factors, though. I'd be interested to go in depth on your and our programming techniques so we can perhaps find a middleground in the sense that everyone's techniques differ and perhaps we could find a median that is sufficient for most programmers.


That would be cool though you might find it better to talk to someone like monoghan or a more experienced MSSQL developer than me about stuff like this they're probably a bit more up to date than me. It's been a while since I did any MSSQL work.

Most of my time is taken up with design these days. Just like to keep up with the programming side of things aswell because I do a bit of that aswell occasionally.

It would be cool to have a chat though because your pointing out this backquote thing has set me off down a path where I've learned some new things that I can perhaps put to some practical use in the future. Even though the back quote doesn't appear to be portable it's at least highlighted the benefit of abstracting field names aswell which I'm going to start doing from now on I think. :)

Hopefully I'll be able to return the favour some time.

[monaghan]

You have no idea how many projects we get with no commenting. It's worse than programming from scratch.

I've re-written several systems rather than trying to understand what the so-called programmer was doing :( How about variables names a,b,c,d etc... ?

I used to remove comments on my dBase 2 code on the DEC Rainbow CP/M machine as each line was a seperate disk read and 5 1/4 disks weren't that fast :)

Once we moved to a PC-DOS machine with a hard disk, all comments have been left in place.

[EthicalDesign]

Originally posted by monaghan: CP/M machine

:D Haven't heard that acronym in a long while.