constant vs. string

Hi all, is there any advantage to using a constant versus a string for databasefields throughout the program? They could look like these:

myRecordSet.Field(kMyfield).Value

myRecordSet.Field(“Myfield”).Value

Back in VB6, the string space had an upper limit on total available space for all strings and could be an issue on big projects. In Xojo, you have control of the syntax color of strings, so it is easier to see the field because they stand out if you use a string. If you use a constant, the color is the same as the generic program statements and harder to read. But is there a memory or speed advantage to using a constant instead of string? Our program has a lot of database code and therefore references a lot of fields.

I tested this a few years ago and there was no difference. Interestingly .Field was even a bit faster than .IdxField. Tested MySQL, PostgreSQL and SQLite only.

You are always better off using a constant for this reason: if you ever have to change the actual string, you will only have to change it in one place.

Other than that, I don’t know how Xojo handles string literals internally although I suspect, when compiled, identical string literals will only be stored once. I wouldn’t worry about upper limits, even in 32-bit.

Also consider using models like ActiveRecord or OrmRecord to store and access your data.

Thanks guys. In other places I use constants because the strings could change, but these are database fields that will never change, and even if they did, I’d be dealing with a much bigger issues anyway. I’ll look into ActiveRecord, just never wanted to make a bunch of changes for code that works as is.

There’s no speed advantage that I know of. The constant is ‘better’ in that you will never mistype your field name which is a big killer since you don’t find out the issue until runtime.

One of the reasons why we like ActiveRecord so much is that you get auto complete for tables and field names as well date type awareness from the compiler.

Dim oRecord as new Data.T_SomeTable //create new record oRecord.sFirstName = "This" oRecord.iDayOfWeek = "Monday" //will throw compiler error because iDayOfWeek is an integer oRecord.Save //don't care if it's new or not. Just save it and let AR handle the code path.

ActiveRecord puts everything into a transaction for you, uses prepared statements and you rarely have to deal with these types of database details.

Thanks, Bob, I’ll check into it soon.