[Luka P.]

When you have for example 4 chars in the string (the part you see), like "Luka", it is actually 5 chars because compiler converts the code to "Luka\0", to end the string. So if you're using s[5] you can only get 4 chars, not 5 (actually you get 5 chars, but the last one is string terminator).

[MrDeath537]

Quote:

Originally Posted by Luka P. When you have for example 4 chars in the string (the part you see), like "Luka", it is actually 5 chars because compiler converts the code to "Luka\0", to end the string. So if you're using s[5] you can only get 4 chars, not 5 (actually you get 5 chars, but the last one is string terminator).

I knew about '\0', but I thought the size is the number of chars you want to copy, not the array size.

[Luka P.]

String = nothing but a array.

[Slice]

@MrDeath, it's still among the 3 slowest methods of copying strings.

[Extremo]

There actually has to be a bug. Because if you declare for example:

pawn Код:

new arr[5];

You can assign 0,1,2,3,4 and 5 is \0

Which makes it:

pawn Код:

arr[0]='a';
arr[1]='b';
arr[2]='c';
arr[3]='d';
arr[4]='e';

So, either way, you must of started with 1 instead of 0.

[Slice]

Quote:

Originally Posted by Extremo There actually has to be a bug. Because if you declare for example: pawn Код: new arr[5]; You can assign 0,1,2,3,4 and 5 is \0 Which makes it: pawn Код: arr[0]='a'; arr[1]='b'; arr[2]='c'; arr[3]='d'; arr[4]='e'; So, either way, you must of started with 1 instead of 0.

No. In PAWN, strings are zero-terminated; this means when a string is being read by, for example, a function, it will read the string until it finds a null-character. If you declare a string like you just did, printing out that string will most likely have lots of other characters after itself.

Edit: Oh, I misread your post. Here's the answer to it:
When you declare an array, it will create the number of slots you specify; therefore, arr[5] will have 0, 1, 2, 3, and 4.

[iggy1]

Extremly usefull and shockingly easy to use include. Takes the ball-ache straight out of creating sqlite databases. Thanks g_aSlice great code. Using now, will report bugs. (if any)

[Slice]

Quote:

Originally Posted by iggy1 Extremly usefull and shockingly easy to use include. Takes the ball-ache straight out of creating sqlite databases. Thanks g_aSlice great code. Using now, will report bugs. (if any)

Are you still using it? How's that going?

[iggy1]

Quote:

Originally Posted by Slice Are you still using it? How's that going?

Yep still using it. Works like a charm. I'll let you know if i run into any problems

[Slice]

Well.. a few people are using this in their gamemode without any problems, so I'm not sure what to update.

[thiaZ_]

Quote:

Originally Posted by Slice Well.. a few people are using this in their gamemode without any problems, so I'm not sure what to update.

Thats what I meant with "Update on what?".

[TheBetaFox]

Quote:

Originally Posted by thiaZ_ Thats what I meant with "Update on what?".

Quote:

// BUD::VerifyColumn( "rawdata", BUD::TYPE_BINARY ); // Not yet supported

BUD::TYPE_BINARY?

Quote:

When I'm done with this, I will make something similar, but more powerful, for MySQL. You won't have to change a line of code to switch to the MySQL version (once it's finished) if you're using this.

MySQL version?

[Slice]

Update

• BUD::GetNamesForSortedData now behaves properly.
• Speed improvements in BUD::MultiGet.

..yes.. a minor update.

The MySQL version won't happen, because the step from a simple user system (which BUD aims to be) to a MySQL user system is too big. It would require refactoring a lot of code as any good use of the MySQL plugins is taking advantage of the threaded functionality.
BUD::TYPE_BINARY might come in the future, depends on whether or not I find a good way to store the raw array data without wasting lots of space.

[Norn]

Quote:

Originally Posted by Slice Update BUD::GetNamesForSortedData now behaves properly. Speed improvements in BUD::MultiGet. ..yes.. a minor update. The MySQL version won't happen, because the step from a simple user system (which BUD aims to be) to a MySQL user system is too big. It would require refactoring a lot of code as any good use of the MySQL plugins is taking advantage of the threaded functionality. BUD::TYPE_BINARY might come in the future, depends on whether or not I find a good way to store the raw array data without wasting lots of space.

sqlite is great imo and it's native, the use of unofficial plugins makes me nervous.

Great script.

[Zh3r0]

<deleted>

EDIT:NEVERMIND!!

I accidentaly skipped this define while I was configuring BUD.inc.

pawn Код:

#if !defined BUD_MAX_COLUMNS
    #define BUD_MAX_COLUMNS  (30)

[Slice]

I updated it so it won't crash when there are too many columns in the database. It'll just tell you to increase BUD_MAX_COLUMNS.

[TheBetaFox]

Strangely, pawncc.exe crashes when I include the new bud.inc in a blank script.
Has this happened to anyone?

[Slice]

Quote:

Originally Posted by TheBetaFox Strangely, pawncc.exe crashes when I include the new bud.inc in a blank script. Has this happened to anyone?

@******: Looks interesting.. May I alter & use that in BUD?

What other things do you include first? Also, are you using Pawno, Notepad++, or that excuse of an IDE called QuickPawn?

[TheBetaFox]

Quote:

Originally Posted by Slice What other things do you include first? Also, are you using Pawno, Notepad++, or that excuse of an IDE called QuickPawn?

I'm using Notepad++, and since it's just the default new.pwn, the only other thing included is a_samp.inc. I find it strange - it happens to me only on blank scripts.
Also, I once got around 22-28 errors from the include itself. I recompiled the gamemode and then it worked.

....I think this would rather be more pawncc.exe's fault, though. It doesn't seem to like Windows 8.

[Slice]

This uses SQLite, you just need to use the functions and BUD takes care of everything else. You can use PDO or the sqlite3_* functions in PHP to connect to the database (which will be in your "scriptfiles" folder).